nix isn't updating vendorHash correctly

[drewr]

Despite our auto-update process, I got this while updating home-manager today.

error: hash mismatch in fixed-output derivation '/nix/store/5kbpl56jlwfq7qg1z50n3byidx398snl-datumctl-dev-go-modules.drv':
         specified: sha256-uYxxIsYFeYfDXKCiW+iWHSrDT4FGkc+5OJlzZwEmo4w=
            got:    sha256-Hj72B7lra2qU+Kj9DKP9P8/AJ3Z2p6MRTikfiSnZkO4=

Even more interesting is when I run update-nix-hash.go locally on 01e0c73 I get a different hash altogether:

$ go run scripts/update-nix-hash.go
Current vendorHash: sha256-uYxxIsYFeYfDXKCiW+iWHSrDT4FGkc+5OJlzZwEmo4w=
Updating vendorHash in flake.nix...
Running nix build to determine correct hash...
Extracted hash: sha256-xxlYC74qdbF4VS3tqbEm78SHQYDS5vIsypZZ8dDg2GM=
Updated vendorHash: sha256-uYxxIsYFeYfDXKCiW+iWHSrDT4FGkc+5OJlzZwEmo4w= -> sha256-xxlYC74qdbF4VS3tqbEm78SHQYDS5vIsypZZ8dDg2GM=
Verifying build with new hash...
warning: Git tree '/Users/aar/src/datum-cloud/datumctl' is dirty
✓ Build successful with new hash

And then the latest workflow run got a totally different hash:

task: [nix-update-hash] go run scripts/update-nix-hash.go
Current vendorHash: sha256-uYxxIsYFeYfDXKCiW+iWHSrDT4FGkc+5OJlzZwEmo4w=
Updating vendorHash in flake.nix...
Running nix build to determine correct hash...
Extracted hash: sha256-slzr63GnNwLM7T9KrwFk33oVEXemEAgWyi4VI4J1Tqw=
Updated vendorHash: sha256-uYxxIsYFeYfDXKCiW+iWHSrDT4FGkc+5OJlzZwEmo4w= -> sha256-slzr63GnNwLM7T9KrwFk33oVEXemEAgWyi4VI4J1Tqw=
Verifying build with new hash...
warning: Git tree '/home/runner/work/datumctl/datumctl' is dirty
this derivation will be built:
  /nix/store/4hjcda8xf29w30scqcgw7vqbg925rqsa-datumctl-dev.drv
building '/nix/store/4hjcda8xf29w30scqcgw7vqbg925rqsa-datumctl-dev.drv'...
✓ Build successful with new hash

[scotwells]

@drewr I noticed it seems to open a PR against main when a PR is opened that changes the go.mod file. Maybe we need to have it push directly to the PR's branch instead of opening a new PR.

[drewr]

Ok, figured it was something like that. It would need to be a check then as well to gate merging before that happens.

[drewr]

Claude did a great job of tracking this down. I ended up closing #78 which was the right PR that never got merged. Going to run the action manually.

TL;DR: The automation IS working correctly, but the PRs it created were never merged. Instead, PR #84 was manually created with an incorrect hash
  and merged, which caused the build failure.

  What happened:

  1. The automation worked correctly:
    - When go.mod was updated (activity v0.2.0 upgrade), the GitHub Actions workflow triggered
    - It correctly computed the new vendorHash: sha256-Hj72B7lra2qU+Kj9DKP9P8/AJ3Z2p6MRTikfiSnZkO4=
    - It created/updated PR #78 with this correct hash
  2. The PRs were never merged:
    - PR #78 (and others: #80, #82) are still OPEN
    - These automated PRs were ignored/overlooked
  3. Manual intervention with wrong hash:
    - PR #84 was created manually with hash sha256-xxlYC74qdbF4VS3tqbEm78SHQYDS5vIsypZZ8dDg2GM=
    - This wrong hash was merged to main via PR #84
    - This caused the build failure you encountered

  Current state:

  # Currently open automation PRs:
  - PR #78: Targets main branch (has the CORRECT hash)
  - PR #80: Targets feat/platform-wide-querying (already merged, stale)
  - PR #82: Targets renovate/go.miloapis.com-milo-0.x branch

  Solution:

  Simply merge PR #78 - it has exactly the correct hash change needed. The diff from PR #78 matches what we just computed locally:

  - vendorHash = "sha256-xxlYC74qdbF4VS3tqbEm78SHQYDS5vIsypZZ8dDg2GM=";
  + vendorHash = "sha256-Hj72B7lra2qU+Kj9DKP9P8/AJ3Z2p6MRTikfiSnZkO4=";

[drewr]

We're gonna go with the solution in #87 as the solution to this.