Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow Gradle daemon to continue running between build steps #113

Closed
bigdaz opened this issue Nov 1, 2021 · 5 comments
Closed

Allow Gradle daemon to continue running between build steps #113

bigdaz opened this issue Nov 1, 2021 · 5 comments
Labels
enhancement New feature or request
Milestone
v2.2.0

Comments

@bigdaz
Copy link
Member

bigdaz commented Nov 1, 2021

The current implementation uses the --no-daemon flag to avoid the need to stop daemons at the end of the job. Instead, we should run the build as configured, keeping track of invocations and running gradle --stop as required at the end of the job.
@bigdaz bigdaz added the enhancement New feature or request label Nov 1, 2021
@bigdaz bigdaz added this to the v2.1 milestone Nov 1, 2021
@bigdaz bigdaz removed this from the v2.1 milestone Dec 30, 2021
@bigdaz
Copy link
Member Author

bigdaz commented Dec 30, 2021

As of v2.1, the daemon is still disabled, but is done via org.gradle.daemon=false in ~/.gradle/gradle.properties.

This means that, pending a fix to this issue, a workflow can provide the --daemon command-line argument when invoking Gradle. Any job that does so will be responsible for stopping the Gradle daemon in a later Step.

@bigdaz bigdaz modified the milestones: v2.1.1, v2.2 Dec 31, 2021
@bigdaz bigdaz mentioned this issue Jan 16, 2022
Merged
@bigdaz bigdaz modified the milestones: v2.2, v2.2.0 Jan 24, 2022
@bigdaz bigdaz mentioned this issue Apr 6, 2022
Closed
@AkselAllas AkselAllas mentioned this issue Apr 12, 2022
Closed
@mikehardy mikehardy mentioned this issue Apr 25, 2022
Merged
mikehardy added a commit to mikehardy/Anki-Android that referenced this issue Apr 26, 2022
@mikehardy
perf(ci): use gradle-build-action w/main cache only on all workflows
a9c225c 
This should optimize LRU cache eviction so main and branches always have
reasonably fresh gradle caches and main does not ever get evicted, since
branches have independent caches and would otherwise fill up 10GB cache limit

Note that `--daemon` is specified as the default for this action is no daemon,
that is correct for long-lived runners to avoid cross-build contamination, but
on GitHub Hosted Runners (which we use) we are clean each run, so this is a small
optimization to share gradle between steps: gradle/gradle-build-action#113 (comment)
mikehardy added a commit to ankidroid/Anki-Android that referenced this issue Apr 26, 2022
@mikehardy
perf(ci): use gradle-build-action w/main cache only on all workflows
3e91bdc 
This should optimize LRU cache eviction so main and branches always have
reasonably fresh gradle caches and main does not ever get evicted, since
branches have independent caches and would otherwise fill up 10GB cache limit

Note that `--daemon` is specified as the default for this action is no daemon,
that is correct for long-lived runners to avoid cross-build contamination, but
on GitHub Hosted Runners (which we use) we are clean each run, so this is a small
optimization to share gradle between steps: gradle/gradle-build-action#113 (comment)
oyeraghib pushed a commit to oyeraghib/Anki-Android that referenced this issue Apr 30, 2022
@mikehardy @oyeraghib
perf(ci): use gradle-build-action w/main cache only on all workflows
fc9b2e7 
This should optimize LRU cache eviction so main and branches always have
reasonably fresh gradle caches and main does not ever get evicted, since
branches have independent caches and would otherwise fill up 10GB cache limit

Note that `--daemon` is specified as the default for this action is no daemon,
that is correct for long-lived runners to avoid cross-build contamination, but
on GitHub Hosted Runners (which we use) we are clean each run, so this is a small
optimization to share gradle between steps: gradle/gradle-build-action#113 (comment)
oyeraghib pushed a commit to oyeraghib/Anki-Android that referenced this issue May 14, 2022
@mikehardy @oyeraghib
perf(ci): use gradle-build-action w/main cache only on all workflows
d2292f7 
This should optimize LRU cache eviction so main and branches always have
reasonably fresh gradle caches and main does not ever get evicted, since
branches have independent caches and would otherwise fill up 10GB cache limit

Note that `--daemon` is specified as the default for this action is no daemon,
that is correct for long-lived runners to avoid cross-build contamination, but
on GitHub Hosted Runners (which we use) we are clean each run, so this is a small
optimization to share gradle between steps: gradle/gradle-build-action#113 (comment)
@LouisCAD
Copy link

@bigdaz

Any job that does so will be responsible for stopping the Gradle daemon in a later Step.

By finalizing with a step running ./gradlew --stop?

@LouisCAD
Copy link

LouisCAD commented May 28, 2022 •
edited

About adding the --daemon option. Is there a way to enable the daemon back without having to append --daemon to every single command? I'd be looking for an environment variable if it can override what's specified in ~/.gradle/gradle.properties.

@bigdaz
Copy link
Member Author

bigdaz commented Jun 3, 2022

Is there a way to enable the daemon back without having to append --daemon to every single command? I'd be looking for an environment variable if it can override what's specified in ~/.gradle/gradle.properties.

I'm not aware of an environment variable that does this. I suppose you could write an action that changes ~/.gradle/gradle.properties after the gradle-build-action runs but before any Gradle build invocation. (This assumes that you're not using gradle-build-action to actually execute your Gradle builds.)

Otherwise, I'm afraid that you'll need to wait until this issue is fixed.

@bigdaz bigdaz closed this as completed in 52ebf27 Jun 6, 2022
@LouisCAD
Copy link

LouisCAD commented Aug 24, 2022 •
edited

Thanks for the fix! Nice to have it now right by default 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
v2.2.0
Development

No branches or pull requests
2 participants
@bigdaz @LouisCAD