config-avoidance
  • 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

    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
    version
    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

    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

    twisterrob

    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, Task1::class.java)
    val task2: VariantTask? = project.findTaskFor(variant, Task2::class.java)
    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? =
       this
          .tasks
          .withType(taskClass)
          .matching { it.variantName == variant }
          .singleOrNull()
    The problem is two-fold as I see it: • find a way to do
    matching
    without creating the tasks • find a way to do
    ?:
    on
    Provider<Task>
    or another way to deal with no matching tasks for variantPlease 🧵 with any response.
  • t

    twisterrob

    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
    Task
    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

    CristianGM

    10/24/2022, 4:30 PM
    I need to know about all
    tasks.withType(X)
    currently I can use
    TaskCollection.getNames()
    but that's not a live/lazy collection, so I need to wrap it in an
    afterEvaluate
    , I would say having
    names
    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
    whenTaskAdded
    , but currently it would realize all tasks too. Any ideas? maybe a live collection version of names could be added
  • v

    Vampire

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