Try enabling gradle enterprise #4923
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jrhee17
force-pushed
the
poc/gradle-enterprise
branch
3 times, most recently
from
4e12352
to
a2e4737
Compare
jrhee17
force-pushed
the
poc/gradle-enterprise
branch
from
89718a7
to
eef3d40
Compare
ikhoon
approved these changes
Jun 8, 2023
| @@ -18,6 +18,7 @@ concurrency: | |||
| env: | |||
| LC_ALL: "en_US.UTF-8" | |||
| BUILD_JDK_VERSION: "19" | |||
| GRADLE_ENTERPRISE_ACCESS_KEY: ${{ secrets.GRADLE_ENTERPRISE_ACCESS_KEY }} | |||
There was a problem hiding this comment.
JFYI, we can set an environment variable on GitHub settings. https://docs.github.com/en/actions/learn-github-actions/variables#creating-configuration-variables-for-an-environment
ikhoon
pushed a commit
to be-hase/armeria
that referenced
this pull request
Jun 12, 2023
Motivation: Note that github secrets are not available for actions triggered by forked pull requests: [ref](https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/#improvements-for-public-repository-forks) We have two choices 1. Using `pull_request` events: - For push (merge) events, secrets are applied and the build cache is updated - For pull requests from forked repositories, the build cache isn't updated. This means we can't take advantage of the build cache when checking out and reviewing pull requests locally. - We can expect fewer cache uploaded, but higher hit rate 2. Using `pull_request_target` events: - For all opened pull requests, secrets are applied and the build cache is updated - For this type of event, the `.github` workflow files from the base commit is used. This means updating the `.github` workflow file can be tedious. (e.g. we need to merge changes we want to test to our forked repo, and then open a PR to verify changes) I think it's fine to go with option 1 for now. Perhaps we can pivot to option 2 later depending on how much pressure our gradle enterprise instance is experiencing. Unfortunately, the only way to test if this PR "works" is to push this commit to the `main` branch. Test result from my forked repo: - PR: jrhee17#10 - Build scan: https://ge.armeria.dev/s/hcdbl7vdcqbhc - CI: https://github.com/jrhee17/armeria/actions/runs/5201312954/jobs/9381342458#step:5:1601 The options provided in `settings.gradle` are straightforward from Step 1 in the provided manual. Modifications: - Add a environment variable for gradle enterprise access key - Add gradle enterprise configurations in `settings.gradle` Result: - Gradle enterprise integration
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation:
Note that github secrets are not available for actions triggered by forked pull requests: ref
We have two choices
pull_requestevents:pull_request_targetevents:.githubworkflow files from the base commit is used. This means updating the.githubworkflow file can be tedious. (e.g. we need to merge changes we want to test to our forked repo, and then open a PR to verify changes)I think it's fine to go with option 1 for now. Perhaps we can pivot to option 2 later depending on how much pressure our gradle enterprise instance is experiencing.
Unfortunately, the only way to test if this PR "works" is to push this commit to the
mainbranch.Test result from my forked repo:
The options provided in
settings.gradleare straightforward from Step 1 in the provided manual.Modifications:
settings.gradleResult: