Add create-diff-link.sh script

[Turbo87]

Replacement for #3835 and symbiotic with https://github.com/rust-lang/crates-io-ops-guide/pull/4 :)

[rust-highfive]

r? @jtgeibel

(rust-highfive has picked a reviewer for you, use r? to override)

[jtgeibel]

One thing to note is that if code is pushed via non-git means, then the fetched branch doesn't reflect the actual commit that is deployed. I've seen this before on staging with deploys done by the ops bot. On production that shouldn't be an issue, but on the rare occasion that we rollback a deploy, the remote repo state and deployed state will diverge.

Also, I wonder if we should parse heroku-prod/HEAD, as at some point we may switch to a main branch which Heroku now supports.

Alternatively, we could extract the deployed commit from the server by fetching https://crates.io/api/v1/site_metadata. This should always reflect the latest deployed commit hash.

[Turbo87]

I've seen this before on staging with deploys done by the ops bot

does that bot not use git to deploy?

Also, I wonder if we should parse heroku-prod/HEAD

let me try if that works, but generally sounds reasonable

Alternatively, we could extract the deployed commit from the server by fetching https://crates.io/api/v1/site_metadata. This should always reflect the latest deployed commit hash.

seems like that would require something like https://stedolan.github.io/jq/ and I was hoping to avoid external dependencies for this script to keep it simple :)

[Turbo87]

$ git rev-parse --short heroku-prod/HEAD
fatal: Needed a single revision

$ git rev-parse --short heroku-prod/master
86ded9db0

unfortunately it doesn't :-/

[jtgeibel]

does that bot not use git to deploy?

I'm not too familiar with that codebase, but this looks like the relevant logic. I believe it makes an API request to Heroku which then fetches from GitHub. From what I recall, that method doesn't update the master branch of Heroku's version of the repo.

let me try if that works, but generally sounds reasonable
unfortunately it doesn't :-/

It looks like git remote set-head heroku-prod -a would lookup the remote HEAD and cache it as heroku-prod/HEAD, however I think that is a one-time operation and would need to either be run every time by the script, or every user would have to remember to run it if we change to a different HEAD branch. Therefore, it seems fine to me to just reference master directly and update the script if we ever rename the branch to main.

seems like that would require something like https://stedolan.github.io/jq/ and I was hoping to avoid external dependencies for this script to keep it simple :)

I agree that it doesn't seem worth adding a dev dependency for this. Also, given that there are only a few of us who will run this script, I think we can remember to tweak the generated URL as necessary if we're end up rolling back a deployment.

This looks good to me, but I'll defer to @pietroalbini for the final r+.

[Turbo87]

From what I recall, that method doesn't update the master branch of Heroku's version of the repo.

I see, thanks :)

[jtgeibel]

@bors r+

[bors]

📌 Commit b7de0c1 has been approved by jtgeibel

[bors]

⌛ Testing commit b7de0c1 with merge 5b6ea9f...

[bors]

☀️ Test successful - checks-actions
Approved by: jtgeibel
Pushing 5b6ea9f to master...