Avoid running PIR fleet binaries on hosted runners#115
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fa88d0761c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "https://github.com/${{ github.repository }}/releases/download/${{ inputs.release_tag }}/SHA256SUMS" | ||
| # The fleet binary targets x86-64-v4, so hosted runners only verify its checksum. | ||
| grep ' nf-server-linux-amd64$' SHA256SUMS | sha256sum --check - | ||
| mv nf-server-linux-amd64 nf-server |
There was a problem hiding this comment.
When a release asset matches SHA256SUMS but is for the wrong dataset/version, this now renames it to the deployable nf-server, and the following SCP step copies it over /opt/nf-ingest/nf-server before the remote dataset-info guard rejects it. In that failure mode the workflow exits before restart, but the rejected binary is left installed on disk on the backup host (and the same pattern exists for primary), so a later reboot/restart can pick up the bad binary; stage it under a temporary remote path and run dataset-info there before replacing the installed binary.
Useful? React with 👍 / 👎.
1 participant
The deploy workflow now verifies
nf-server-linux-amd64against the releaseSHA256SUMSinstead of executing the x86-64-v4 fleet binary onubuntu-latest. Ironwood dataset validation still runs on each PIR host before restart.