Manually generate distribution archives #1032
Conversation
| TAG=${GITHUB_REF_NAME} | ||
| PREFIX="rules_python-${TAG}" | ||
| ARCHIVE="rules_python-$TAG.tar.gz" | ||
| git archive --format=tar --prefix=${PREFIX}/ ${TAG} | gzip > $ARCHIVE |
There was a problem hiding this comment.
Adding a prefix here and asking users to add strip_prefix in http_archive seem unnecessary?
There was a problem hiding this comment.
I'm guessing it was done that way to match the github-generated archives? I'm just leaving it as is for now so that it's less config people need to change.
There was a problem hiding this comment.
Because of today's incident, there is no point of matching the sha256 of github-generated archives. FYI: rules_go and Gazelle's release archives are independent from github-generated ones too:
https://github.com/bazelbuild/rules_go/releases/tag/v0.38.1
https://github.com/bazelbuild/bazel-gazelle/releases/tag/v0.29.0
There was a problem hiding this comment.
Yes, I know. I'm not trying to match the sha256. I'm just keeping the structure the same, because it's a nicety to not have to change both url and the strip_prefix setting.
There was a problem hiding this comment.
+1 for keeping it the same
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Right now, we use the automatically generated GitHub source archives. These have had issues with GitHub changing how they're generated, which affects the checksums, which then breaks users.
Issue Number: #1031
What is the new behavior?
A tar.gz is manually generated using
git export. Some online sources indicate this is the underlying mechanism github uses for generate their archives. We also use this for computing the checksum, so that comports.Does this PR introduce a breaking change?
Though note that base filename changes
Other information
This happened previously a year to so ago, too.