Can we stop requiring release archives to be uploaded as part of publishing the release

[lalten]

BCR likes source archives to be uploaded as release artifact rather than relying on the automatic source artifact for commits and tags which is known to not have a guaranteed hash.
Currently if users configure publish-to-bcr to point at a release artifact in the source.template.json, the app will fail with the message ensure that the release archive is uploaded as part of publishing the release rather than uploaded afterward..

GitHub supports a workflow where it automatically tags the repo with the a tag chosen in the release "editor". I like that approach because it saves me some brain power trying to do the tagging exactly right using git. The drawback is that I can't use GitHub Actions to publish the release on tag creation like suggested in the https://github.com/bazel-contrib/rules-template/blob/main/.github/workflows/release.yml

I don't know if it really makes sense that the app stops on the mentioned error. The BCR PR could be made anyways. It will fail if CI runs on it -- but only until the author has manually attached the release artifact to the release.

Another idea to work around this issue would be to have the bot download the automatic source archive and re-upload it as the attached release archive.

Curious about people's opinions here.

[kormide]

I think it makes sense that not being able to download the release archive shouldn't cause a hard failure. The release archive needs to be present to calculate the correct integrity value, but the PR could always be manually amended after it's up.

I'll think about this some more and let it stew.

[kormide]

Actually, I don't think this will be possible. The MODULE.bazel file in the release archive is the source of truth for the module name which forms the path in the BCR repo, and the module file itself that appears in the BCR entry. It's not required that a module published to the BCR comes from a source archive that even has a MODULE.bazel file. This was the case for at least some rulesets were made available via bzlmod before supporting being built with bzlmod themselves.

[kormide]

There is some leniency for release archives that are uploaded shortly after the release is created. The download happens with retries and exponential backoff. I could increase the number of retries if that would be helpful.

[lalten]

Increasing the retry number or timeout would help I think.
I added a release upload workflow in lalten/rules_appimage@b3975c4 which correctly uploaded an artifact to my test (pre-)release https://github.com/lalten/rules_appimage/releases/tag/test-auto-release-upload.
But the publish-to-bcr bot still complained Failed to download release archive from https://github.com/lalten/rules_appimage/releases/download/test-auto-release-upload/rules_appimage-test-auto-release-upload.tar.gz. Received status 404 -- that URL was perfectly downloadable when I clicked the link in the mail.

[lalten]

Haha or maybe it did something? The bot did put up bazelbuild/bazel-central-registry#1436 and apparently failed to interpolate some vars in the process.