• s

    Satyarth Sampath

    07/19/2022, 2:42 PM
    Hey Folks, Is there a way to identify((in a build scan) ) which tasks were created during configuration ? I’m following the Task Configuration Avoidance guide which then shows me that some tasks were created during configuration. However I cannot identify which tasks were created.
  • CristianGM


    07/20/2022, 9:36 AM
    I was trying to enable configuration-cache at CI, but I'm finding it very hard, everyone seems to read environment variables everywhere. First example: MavenPublication
    is a string, not a property, so as we use our CI build number (it's an env var) we can't do anything. In this case I think MavenPublication should allow us to use Properties so it's only read in execution time.
  • CristianGM


    07/20/2022, 9:38 AM
    another example: com.gradle.common-custom-user-data-gradle-plugindoes read a lot of env vars, you may think it's my fault for using it, but the thing is, GE Scans benefit from all that info, is just that we shouldn't need it in configuration time
  • v

    Vladimir Sitnikov

    07/13/2022, 2:37 PM
  • p

    Paul Woitaschek

    07/26/2022, 5:22 AM
    We use Gitlab and for our internal maven repo use the CI_JOB_TOKEN. As that one is changing this is also completely preventing the usage of config Cache on the CI (this is an answer to the two threads above )
  • t


    08/17/2022, 8:21 AM
    I'm having a fun problem. I have eager code that I want to turn in to lazy, but it's not clicking how to. Here's a simplified version of the code:
    val task1: VariantTask? = project.findTaskFor(variant,
    val task2: VariantTask? = project.findTaskFor(variant,
    val task = task1 ?: task2
    if (task != null) { task.dependsOn(someOtherTask) }
    and the definition of the utility
    private fun <T : VariantTask> Project.findTaskFor(variant: String, taskClass: Class<T>): T? =
          .matching { it.variantName == variant }
    The problem is two-fold as I see it: • find a way to do
    without creating the tasks • find a way to do
    or another way to deal with no matching tasks for variantPlease 🧵 with any response.
  • t


    08/21/2022, 5:59 PM
    My first idea is to do
    project.tasks.configureEach { created.add(it) }
    and then invoke
    gradlew :help
  • Łukasz Wasylkowski

    Łukasz Wasylkowski

    10/14/2022, 10:38 AM
    Hey folks, do I understand correctly that running
    ./gradlew <anyTask> --dry-run
    should never create a single
    instance during configuration phase, and if it does — that’s a place for improvement/fix? Even if the fix is not possible for some reason, no tasks created would be ideal, right?
  • CristianGM


    10/24/2022, 4:30 PM
    I need to know about all
    currently I can use
    but that's not a live/lazy collection, so I need to wrap it in an
    , I would say having
    as a live collection, would be great. I want to know about the tasks, not to realize them all. Another approach would be using something like
    , but currently it would realize all tasks too. Any ideas? maybe a live collection version of names could be added
  • v


    10/26/2022, 1:31 PM
    cause all tasks of
    to be realized? o_O I see task
    to be realized and configured although it is registered, nowhere depended on, and also not triggered by command line.