github-actions does not have permissions to push to main

[UebelAndre]

In #663 a change was introduced to build new crate_universe_resolver binaries and push a change back to main containing the release URL where they were uploaded and the sha256 checksums of each binary. Unfortunately, the github-actions user cannot push to main.

https://github.com/bazelbuild/rules_rust/runs/2289735079?check_suite_focus=true

 [main 632d30b] github-actions: update crate_universe binaries from a3c2741207a205e5421f3b3632e578f07ccd26cc
 1 file changed, 6 insertions(+), 6 deletions(-)
remote: error: GH006: Protected branch update failed for refs/heads/main.        
remote: error: 2 of 2 required status checks are expected. At least 1 approving review is required by reviewers with write access.        
To https://github.com/bazelbuild/rules_rust
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/bazelbuild/rules_rust'

[UebelAndre]

I think only @hlopko has the power to help out here.

[dfreese]

Is bootstrapping cargo_universe requiring auto-commits back into the repository?

[UebelAndre]

The bootstrapping process doesn't but being able to distribute the built binaries to users does. Otherwise users need to go get the URLs and sha256 values themselves which is not ideal.

[dfreese]

I'm not comfortable with the repository being auto-updated for a API that's experimental.

[UebelAndre]

Why are you uncomfortable? And what are the alternatives?

[dfreese]

The API takes the url and sha256 as an input. The SHAs could be generated as an additional artifact.

auto-commits are a significant jump in complexity to getting something working, and making sure they continue to work.

[UebelAndre]

I don't see how an additional artifact would solve for users having to copy/paste something in addition to having to go find the latest commit of the rules and the sha256 of these rules to use a built in rule.

How do we solve for the usability concerns?

[dfreese]

Given that most bazel repositories require a user to locate it's url and SHA, I don't see it as a huge usability hurdle.

[UebelAndre]

I do see it as a sizable usability hurdle. I'd like to avoid putting users in situations where they're using incompatible binaries with their current rev of the rules.

I hope to stabilize crate_universe as soon as possible and think it's appropriate to have the CI system commit updated info on the new binaries. If the rule being experimental is your primary concern, we could work something out but I feel it's best enable functionality like this so it has as much time as possible to mature.

[dfreese]

To clarify my concern, it being experimental is a secondary concern.

I think every commit of the repository should function appropriately, and if the API requires a secondary commit for every change, then it doesn't seem to be following that principle.

[UebelAndre]

Aside from committing binaries to the repo, what other options are available?

[illicitonion]

I agree that atomic self-contained commits are much nicer than separate ones (both ideologically, and for making things like bisects work properly). I can see the desire to avoid the complexity of auto-commits (at least for now) from a complexity perspective, but I don't think auto-commits are fundamentally problematic, other than that they break the self-contained-ness of commits.

It feels like the ideal way to address this long-term would be for a bot to perform the merges for us (and do the generation on the way), rather than for us to merge and then trigger another process.

In the mean time, I can imagine the now-existing "release" GitHub Action populating a copy-and-paste-able WORKSPACE block so that on https://github.com/bazelbuild/rules_rust/releases/tag/crate_universe-3 under where it says "From commit [blah]" it would then say:

load(..., "http_archive", "http_file")

http_archive(
    name = "rules_rust",
    url = "[rules_rust tar]",
    sha256 = "...",
    ...
)

http_file(
    name = "rules_rust_crate_universe_resolver_darwin_...",
    url = "[rules_rust tar]",
    sha256 = "...",
)

...

So that the primary way someone pulls in rules_rust is by copying this block. The rules could be written assuming you've registered the repos, and just consuming them assuming they have been.

Given bootstrapping for development and for PR builds needs to be separate anyway, changing from copying one http_archive to N http_* rules doesn't seem too onerous... Certainly while this is experimental, it seems good enough for us to use for development, at least :)

[UebelAndre]

That's a fine solution for right now but I'd like to hear ideas about a long term solution.

Eventually we should have something more streamline and I'd rather have conversations about what options there are vs things we don't like.

[UebelAndre]

Merging things into user's PR sounds risky and tough. Does anyone know of another repo that does this?

[UebelAndre]

This is no longer relevant due to #1195. Closing.