Created a nightly job to run against future Gradle versions #430
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
…in permissions Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com> Signed-off-by: Gašper Kojek <[email protected]>
erichaagdev
left a comment
erichaagdev
left a comment
There was a problem hiding this comment.
Looks good so far, just a few suggestions.
| uses: gradle/actions/setup-gradle@v4 | ||
| with: | ||
| develocity-access-key: ${{ secrets.DV_SOLUTIONS_ACCESS_KEY }} | ||
| gradle-version: 'release-candidate' |
There was a problem hiding this comment.
I think we should focus only on verifying plugin compatibility here.
The primary goal of testing against RC/nightly versions is to catch compatibility issues in the plugin for users proactively. Any incompatibilities with the project's build are less critical and can be handled with the Wrapperbot PR that upgrades the Gradle version.
There was a problem hiding this comment.
While that's true, the release-candidate should be stabile enough to use for building IMO, I'd say we want to be as up to date as possible if someone does take this projects build as a sample.
There was a problem hiding this comment.
It might be stable enough, but I still feel we should build with the Wrapper version. This workflow should only focus on verifying whether the current state of main is compatible with upcoming Gradle releases. Anything else should be outside the scope of this workflow.
If someone uses this project as a sample, they will also build using the Wrapper version unless they take it upon themselves to upgrade the Wrapper, at which point the possibility of incompatibilities should be expected.
There was a problem hiding this comment.
Since we're testing against future Gradle versions and it's not blocking any release cycles or anything like that, I still feel we should be proactively fixing any issues that may pop up with a new Gradle RC version when building the CCUD itself. This feels like a perfect opportunity to ensure that.
Empty lines, workflow (file) name, changed project under test name, added gradle and jdk versions as custom values
…data-gradle-plugin into gk/nightlyGHA * 'gk/nightlyGHA' of github.com:gradle/common-custom-user-data-gradle-plugin: Potential fix for code scanning alert no. 13: Workflow does not contain permissions # Conflicts: # .github/workflows/build-verification-nightly.yml
…es in the 'Verify build' workflow as well
ribafish
force-pushed
the
gk/nightlyGHA
branch
from
3fa26b4 to
c6ae7d1
Compare
erichaagdev
left a comment
erichaagdev
left a comment
There was a problem hiding this comment.
One minor suggestion, but otherwise LGTM!
Co-authored-by: Eric Haag <[email protected]> Signed-off-by: Gašper Kojek <[email protected]>
Created a nightly job to run against future Gradle versions. The building and publish to maven local are executed with the next release candidate, testing against the published artifact is done against the current, rc and nightly Gradle versions.