https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
What does your "bootstrap" task do? How about 
tasks.configureEach { dependsOn(tasks.bootstrap) }
?
a
We are not planning a 7.4.3. I would love to see your "bootstrap" task in full.
k
@Vampire we've actually talked a bit about this... https://gradle-community.slack.com/archives/CA7UM03V3/p1649277324153979 @Amanda: the bootstrap task is mainly something that can run a bunch of other tasks but that is always run first even if you're running on the command line or in the IDE. Stuff it currently does: • make sure all versions of AS/IntelliJ on the system are configured correctly (this includes enforcing plugins are installed or removed, setting up configuration files in .idea, setting up the VMOptions for the heap size, setting up the correct JDK to use so IDE/command line use the same one, setting up IDEA settings, etc.) • configure iterm2 • configure ~/.gradle/init.d scripts • configure .gitconfig • configure Flipper and its plugins • downloading artifact JAR files It's basically to make sure a developer's environment is perfectly set up. I think if we could get bootstrap-init.kts to run a task instead of just inline groovy, it would probably also work, but AFAIK, that's not possible. And this bootstrap plugin/task is specific to our project while bootstrap-init.kts is run on any gradle project on your machine.
👍 1
For 7.5, the code we have in 7.4 to add this initial bootstrap task causes a stack overflow...we do this:
Copy code
gradle.taskGraph.whenReady {
    withGroovyBuilder {
        val executionPlan: ExecutionPlan = getTypedProperty("executionPlan")
        executionPlan.addEntryTasks(listOf(taskProvider.get()))
        executionPlan.determineExecutionPlan()
    }
}
I'll see if we ever opened up an issue for this...
c
doing a lot of similar “setup dev environment” work via init scripts without tasks.
🙌 1
with parts of that work in convention plugins (e.g. golang plugin that sets up golang dev environment)
k
How do you control the init scripts and share setup code across projects? We also have convention plugins FYI....lots of them....
c
init scripts are part of a custom gradle distribution. though, if that’s not doable, you could distribute them into a private repo and have a convention plugin that grabs them and updates them into ~/gradle/init.d.
most of our “dev environment standardization” is a combination of init scripts + a core plugin, with some tech-specific pieces thereafter via other convention plugins (e.g. the golang stuff).
k
have a convention plugin that grabs them and updates them into ~/gradle/init.d
Doesn't this happen too late? i.e. we'd like all of this set up before the convention plugin runs... I think your method is working for you because you have a custom gradle distribution...so you solve this chicken vs. egg thing by doing this 🙂
c
It works for updating scripts, though they won't take effect until next execution. Yes, we ended up with custom distribution to cleanup cyclic dependencies.
👍 1
k
so hypothetically, if you could insert a "bootstrap" task in place of all your init.d scripts, would you? 🙂 We did it because it lets our bootsubtasks run in parallel as well as take advantage of config caching... You wouldn't need your custom gradle distribution I think...
c
Unlikely. Currently most of the setup is quick enough that time isn't a material factor. If we did need to address that would use a build service. Would still keep custom distribution for other reasons.
k
@Amanda: repro for the 7.5rc1 issue I mentioned if you can nudge some folks to have a quick look before 7.5 is released 🙂 https://github.com/gradle/gradle/issues/20940
👍 1
a
Thanks Ken! I will have a look and push accordingly 😉
thank you 1
Open in Slack
PreviousNext
Powered by