chore(deps): update taiki-e/install-action digest to 84f5ac3

[mergeraptor]

This PR contains the following updates:

Package	Type	Update	Change
taiki-e/install-action (changelog)	action	digest	7b8d471 → 84f5ac3

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.

[mergeraptor]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[kubestellar-hive]

🛑 Fix loop escalated — human attention needed

This PR has failed CI on 1 distinct fix attempts (new commits, still red). The hive has stopped dispatching further automated fixes for it.

Failing checks: build

Raw failure evidence (from check-run annotations):

build: Process completed with exit code 255.

Remove the needs-human label after addressing the root cause to return the PR to the automated fix lane.

[kubestellar-hive]

🛑 Fix loop escalated — human attention needed

This PR has failed CI on 1 distinct fix attempts (new commits, still red). The hive has stopped dispatching further automated fixes for it.

Failing checks: build

Raw failure evidence (from check-run annotations):

build: Process completed with exit code 255.

Remove the needs-human label after addressing the root cause to return the PR to the automated fix lane.

[hanthor]

The digest bump is fine. The rest of this PR is not.

I verified the advertised change and it is correct:

$ git ls-remote https://github.com/taiki-e/install-action | grep 84f5ac3124727fb3d284d4d22ee9ab3654fd09a6
84f5ac3124727fb3d284d4d22ee9ab3654fd09a6	refs/tags/v2.87.7

The digest is a real published tag in the v2 line, so the # v2 comment is accurate. If this PR only touched taiki-e/install-action, it would be ready. It does not.

1. Undisclosed hunk: this PR also moves gnome-build-meta 5 commits past its tag

The title and body describe one thing: 7b8d471 → 84f5ac3. The diff contains a second, unmentioned change:

$ git diff main...pr49 -- elements/gnome-build-meta.bst
-  ref: 50.4-0-g8524013485013dd5616bfff02dbeab274d5a4553
+  ref: 50.4-5-gd78f4981a3321e07ae4c62d4a7761de46ac8172b

That came from the track-refs job, not from Renovate. Upstream confirms what each ref is:

$ git ls-remote https://gitlab.gnome.org/GNOME/gnome-build-meta.git "refs/tags/50.4^{}" "refs/heads/gnome-50"
8524013485013dd5616bfff02dbeab274d5a4553	refs/tags/50.4^{}
d78f4981a3321e07ae4c62d4a7761de46ac8172b	refs/heads/gnome-50

So main is pinned exactly to the 50.4 tag, and this PR moves it to the current tip of the gnome-50 branch. That is a real upstream change to the OS composition riding inside a PR labelled as a GitHub Action digest update.

2. That bump re-applies a change that was already reverted for breaking the build

This branch's own history says the gnome-build-meta move off 50.4-0 was reverted on purpose. Commit 02c22de / a82e952 on this same branch:

fix: keep server build on compatible GNOME metadata
Revert gnome-build-meta to the known-good 50.4-0 revision. The 50.4-1 update pulls an FSDK change whose linux-firmware composition overlaps runtime files, causing os-rootfs to fail before image generation.

track-refs has now silently pushed it forward again — past 50.4-1, all the way to 50.4-5 — undoing that revert with no discussion.

3. The current head has never been built by CI

mcp__github__pull_request_read(method="get_check_runs", pullNumber=49)
  -> {"total_count":0,"check_runs":[]}

Zero checks on fbe321c. The workflow run list explains why:

head_sha	commit	conclusion
fbe321c (current head)	chore: resolve BuildStream junction refs…	action_required
9bf45ec	ci: retry transient failing checks	success
110c070	chore(deps): update taiki-e/install-action digest	failure

Every commit authored by github-actions[bot] from the track-refs push lands in action_required and never executes — 7dcc0621, d320675f, 3e06afab, 8c9e8e33, 34d3ffc0 all show the same conclusion. The one green run on this branch (34528096011) was on 9bf45ec, which is the commit before the gnome-build-meta ref was rewritten. Nothing green has ever included the change in item 1.

Worth noting as a workflow bug in its own right: track-refs pushes with the workflow GITHUB_TOKEN, and pushes made with that token do not trigger new workflow runs. The job is structurally incapable of getting its own output tested.

4. Automerge is enabled on this state

The body says 🚦 Automerge: Enabled, and the PR carries both automerge and needs-human. An unbuilt, unreviewed upstream OS bump that was previously reverted for breaking os-rootfs is one green check away from landing on main unattended.

What I'd like to see

1. Drop the elements/gnome-build-meta.bst hunk from this PR — reset it to 50.4-0-g8524013, matching main. The digest bump then stands alone and is mergeable.
2. Propose the gnome-build-meta move separately, where it can get a build that actually runs and where the earlier revert can be discussed.
3. Until track-refs's push can trigger CI, treat any commit it authors as untested regardless of what the checks column shows.

Baseline note: main at 7f376fa is fully green locally — 201 passed, 1 xfailed (pytest), 41/41 bats, and all three .github/scripts checkers exit 0. None of the above is pre-existing breakage.

---

Generated by Claude Code