Enable CI, disable CD

[palinatolmach]

This PR re-enables CI on this repository and removes all secret usage from it, which makes it safe to run again. It also drops the secret-based CD entirely rather than converting it: the release workflow is removed here and comes back, secret-less, in a follow-up PR.

It performs the following updates:

• Removes auto version bumps and release-cutting on master, along with release.yml itself. There is no release automation left in this repository. This will be updated in a follow-up PR.
• Removes Nix/Cachix cache and gh-pages docs deploys, Slack notifications, the devops dispatch, and the check-cachix-pin.sh helper that verified the Cachix push.
• Removes the dependency-bump automation that synced deps/* into kevm-pyk/pyproject.toml, kevm-pyk/uv.lock and flake.{nix,lock}; the _update-deps/* cron is not running, so that sync is manual for now.
• Bumps all pulled-in actions to the latest (checkout v7.0.1, setup-python v7.0.0, setup-uv v9.0.0) and pins every one of them to its commit SHA.
• Sets permissions: contents: read on test-pr.yml and persist-credentials: false on its checkouts, so the CI token is minimal regardless of the repository default, and no credential is left behind in the workspace.
• Passes the with-docker action's inputs through env: instead of interpolating them into the shell block, which removes the template-injection exposure in the action that runs PR-authored code on the self-hosted runners.
• Makes the Docker teardown best-effort and switches the deprecated --time flag to --timeout.

[yiyi-wang-rv]

Reviewed the whole diff. The core goal is achieved and verified: grep -rn "secrets\." .github/ now returns exactly one hit, the auto-issued secrets.GITHUB_TOKEN in release.yml. I also checked the two subtle things this design leans on, and both hold:

• No self-trigger loop. release.yml pushes to release, which is its own trigger branch — but pushes made with the built-in GITHUB_TOKEN do not create new workflow runs, so this terminates. Worth a one-line comment in the file, since it is load-bearing and invisible.
• git push still works after the checkout bump. actions/checkout v6 moved credentials to a separate file, but persist-credentials still defaults to true in v7, so the pushes in the release job authenticate.

I verified the action versions too: actions/checkout@v7 and actions/setup-python@v7 both exist and publish floating major tags; astral-sh/setup-uv genuinely has no v8/v9 floating tag (git/matching-refs/tags/v9 returns only v9.0.0), so the exact pin in commit 2 is correct and necessary. gh release create without --notes does not error in a non-TTY (create.go only prompts when IO.CanPrompt()), so the release step will not fail on that.

Findings inline. The two I would resolve before merging:

1. node24 on the self-hosted runners — checkout@v7/setup-python@v7/setup-uv@v9 are all using: node24; v4 was the last node20 checkout. The self-hosted normal/fast/ARM64 runners need a recent enough actions-runner or every conformance/proof/nix job dies at the checkout step. This is the most likely thing to actually break.
2. Deleting update-version.yml breaks the dependency-bump pipeline, which is still live (#2864/#2865/#2866 all came from rv-jenkins pushing _update-deps/runtimeverification/k in the last few days). Its secrets were replaceable rather than load-bearing — details inline.

Smaller: cancel-in-progress: true on a workflow that now pushes commits and cuts releases can half-apply and silently skip a version; the release is published with no build verification, where the old flow gated promotion on a successful Nix build; and test-pr.yml has no permissions: block.

One nit on the PR description: it lists a DockerHub image publish among the removals, but I don't see one anywhere in the diff — the only Docker usage is .github/workflows/Dockerfile via the local with-docker action, which is untouched CI infrastructure.

[yiyi-wang-rv]

Re-audited all 8 new commits. This is in good shape — everything I raised is addressed, and I verified each fix rather than taking the reply at face value. One new finding, non-blocking, inline on package/version.sh.

Verified fixes

SHA pins — resolved all three against the tag objects; every one matches its comment:

pin	tag object	claimed
actions/checkout@3d3c42e5…	3d3c42e5aac5ba805825da76410c181273ba90b1	v7.0.1 ✅
actions/setup-python@5fda3b95…	5fda3b95a4ea91299a34e894583c3862153e4b97	v7.0.0 ✅
astral-sh/setup-uv@c771a70e…	c771a70e6277c0a99b617c7a806ffedaca235ff9	v9.0.0 ✅

node24 on self-hosted runners — agreed, and confirmed independently: run 31393430707 is green on all 12 jobs, covering [self-hosted, linux, normal], [self-hosted, linux, fast], and both normal and ARM64. That was the finding I was least able to settle from the diff, so having it exercised end-to-end closes it properly.

Dropping the with: block — checked the two things this now depends on. persist-credentials still defaults to true in checkout v7 (v6 moved credentials to a separate file but kept the default), so git push origin HEAD:release still authenticates; and for a push event the default ref is refs/heads/release at exactly github.sha, which is strictly better than the old ref: release.

enable-cache: false — valid and does what the comment says: getEnableCache() in setup-uv/src/utils/inputs.ts is enableCacheInput === "true", so anything other than "true"/"auto" disables it. Good instinct not to restore a cache into the one workflow holding contents: write.

version.sh cleanup — behaviour-preserving, and worth saying why so nobody re-adds the guard: the old code read version and current_version from the same file, so major == major && minor == minor was always true and the patch was always incremented. The deleted branch was unreachable, not a major/minor code path. The new comment about a hand-set line starting at X.Y.1 is accurate.

--draft / --generate-notes / --repo dropped, cancel-in-progress: false, contents: read — all good, and the header comment now explains the one gap CI doesn't cover, which is the right thing to write down.

release-<version> tags — your reply checks out: kontrol's flake.nix pins kevm.url = "github:runtimeverification/evm-semantics/v1.0.921" alongside deps/kevm_release, so it consumes v<version>, not release-*. No consumer to break.

Docker teardown — I was initially wary of || true on a teardown step, since it can hide a real leak on a long-lived self-hosted runner. Pulling the log from the pre-fix run (d825b52) shows the change is well-motivated: the registry mirror returned EOF, Set up Docker failed, and teardown then emitted No such container: kevm-ci-concrete-<sha> plus a second ##[error] Process completed with exit code 1 — exactly the duplicate-failure noise the comment describes. --time is also genuinely deprecated now (Flag --time has been deprecated, use --timeout instead on Docker 28), and the self-hosted daemons accept --timeout: the teardown steps in the green run succeeded rather than being silently swallowed by || true, which is the distinction I wanted to confirm.

update-version.yml

Agreed, and your reasoning is better than mine — if the cron is down, nothing regresses today, and this PR shouldn't be blocked on rebuilding an automation whose trigger doesn't fire. One ask: file a tracking issue rather than leaving it in the PR thread. The failure mode is delayed rather than absent — when the cron comes back it will start opening _update-deps/* PRs that carry only the deps/* file and fail CI, and at that point the context for why the workflow went away will be hard to recover.

Operational note on --draft

Not a code issue, just worth writing into the release runbook: a draft release does not create the git tag until it is published, and the Slack notifications are gone, so nothing announces that a draft is waiting. Until someone clicks publish, downstream pins like kontrol's github:runtimeverification/evm-semantics/v<version> will 404 on the new version. That is the intended trade for gating publication on a human, but the human now has to know to show up.

Verdict

Approvable from my side. The uv lock point below is a follow-up, not a blocker.

For the kontrol port, the three checks that actually earned their keep here: resolve every pinned SHA against its tag before merging, exercise the self-hosted runners once for the node24 bump rather than reasoning about runner versions, and check whether kontrol has its own deps/-driven update-version flow that would be deleted along the same lines — the same delayed-failure question applies there.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.