Create release scripts for rules_pkg_providers#1028
Create release scripts for rules_pkg_providers#1028tonyaiuto merged 4 commits intobazelbuild:mainfrom
Conversation
aiuto
force-pushed
the
prov2
branch
4 times, most recently
from
6300495 to
7f847df
Compare
- generalizable to more modules. - creates the tarball and relnotes as part of the distro package. Future work: - figure out something for BCR releases. - Hope for: bazel-contrib/publish-to-bcr#368 - more pragmatic solution might be to have a shell script around the bcr add-module script - generate git changelog on a per-subdir basis - allow better customization of release notes documentation link
|
@cgrindel Friendly ping. |
cgrindel
left a comment
cgrindel
left a comment
There was a problem hiding this comment.
Overall, LGTM. However, I added a couple of comments/questions.
.github/workflows/checks.sh
Outdated
| exit_code="$?" | ||
| if [ "${exit_code}" -ne 0 ] ; then | ||
| exit "${exit_code}" | ||
| fi |
There was a problem hiding this comment.
With -o errexit, do you need to check for exit_code? My read is that the script will halt if an error occurs.
There was a problem hiding this comment.
TBH. I was lifting code from elsewhere, where they had this heavy-handed style. Removed.
| curl -o "${RUNNER_TEMP}/buildozer" -L "https://github.com/bazelbuild/buildtools/releases/download/v7.3.1/buildozer-linux-amd64" | ||
| "${RUNNER_TEMP}/buildozer" "set version ${VERSION}" "//${SUBDIR}/MODULE.bazel:${MODULE}" || true |
There was a problem hiding this comment.
Is updating the version in the MODULE.bazel a personal preference? I was under the impression this was not necessary if you use the publish to BCR workflow.
There was a problem hiding this comment.
We won't be able to use the publish BCR workflow directly. That only works if every submodule publishes at the same version level, which defeats the point of having a slow release cycle.
| release: | ||
| name: "Create GitHub release" | ||
| needs: | ||
| - "create_tag" | ||
|
|
||
| uses: "bazel-contrib/.github/.github/workflows/release_ruleset.yaml@v7.2.4" | ||
| with: | ||
| # This will run release_prep.sh to do the dirty work. | ||
| # TODO: https://github.com/bazelbuild/rules_pkg/issues/1031 | ||
| release_files: "bazel-bin/distro/rules_pkg_${{ inputs.subdir }}-*.tgz" | ||
| tag_name: "rule_pkg_${{ inputs.subdir }}-${{ inputs.version }}" |
There was a problem hiding this comment.
FYI. There are GHA actions for creating releases (e.g., https://github.com/softprops/action-gh-release) and their associated tags. I wonder if some of the code in release_prep.sh could be replaced by the functionality in the action.
There was a problem hiding this comment.
Maybe. I don't particularly like the constraints of release_ruleset that it always runs release_prep.sh., so I'm willing to switch. OTOH, its not clear that softprops does built attestations yet. I would like to be able to enable those, so release_ruleset might have the short term advantage.
3 participants
providersfor now.Hand testing release_prep.sh seems to work. Testing the workflow is nearly impossible until it exists the first time.
Next steps:
Future work: