-
Notifications
You must be signed in to change notification settings - Fork 35
Refactor CI #104
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.
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
Refactor CI #104
Conversation
WalkthroughUpdates CI workflows: introduces a global JAVA_VERSION and pins/upgrades actions in .github/workflows/build.yml, adds checksum calculation, signing/attestation, and merges Central/GitHub-package deployment and release creation into the build pipeline as downstream jobs. Removes standalone publish-central.yml and publish-github.yml workflows. Updates Java version and pins actions in codeql-analysis.yml and dependency-check.yml. Changes include workflow permission expansions, artifact provenance steps, and CHANGELOG.md notes about pinning CI actions. Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @.github/workflows/build.yml:
- Around line 14-18: The job-level permissions block is missing repository
contents read access so checkout will fail; update the permissions section (the
permissions: block in the build job) to include contents: read alongside
id-token: write and attestations: write so actions/checkout can read the repo
(i.e., add the contents: read permission to the permissions mapping).
- Around line 69-103: The "Enforce to use tagged version" step in the
deploy-central job uses an undefined shell variable $GIT_TAG causing
versions:set to fail; replace it with the correct GitHub Actions tag variable
(github.ref_name or the runner variable GITHUB_REF_NAME) or export it into the
step environment before calling ./mvnw; update the step referenced by its name
"Enforce to use tagged version" to use $GITHUB_REF_NAME (or set
GIT_TAG="${GITHUB_REF_NAME}" in the run block) so versions:set receives the
actual tag value.
♻️ Duplicate comments (1)
.github/workflows/build.yml (1)
104-135: Same undefined$GIT_TAGin deploy-github.
Apply the same fix as the deploy-central job.
overheadhunter
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we want to make "all builds equal", we might also want to make this build reproducible? since we already use mvnw, it's a small change to the pom.xml:
- fix all plugin versions (including default plugins such as
maven-clean-plugin) - add
project.build.outputTimestamp(can be an arbitrary but fixed date such as 2000-01-01) - verify if two builds yield identical artifacts:
./mvnw clean install./mvnw clean package artifact:compare -DskipTests
|
@overheadhunter Regarding reproducible builds: I want to adjust the pom in a follow-up PR. This focus solely on the CI. |
This PR aligns the CI to other, already updated repositories (e.g. siv-mode or cryptofs).
It