Automated patch releases for devcontainer-native on main

[jooh]

Motivation

• Automate cutting a patch release when main is updated and start semantic versioning at 0.0.1 for the Rust native crate.
• Ensure the crate is built and a distributable artifact plus checksum are published to GitHub Releases on each patch bump.

Description

• Add a new workflow file .github/workflows/devcontainer-native-release.yml that runs on push to main and has permission to create releases.
• The workflow computes the next patch from tags with prefix devcontainer-native-v, defaults from 0.0.0 to produce 0.0.1 for first release, and writes version/tag outputs.
• The workflow updates the crate version in cmd/devcontainer-native/Cargo.toml, runs cargo build --release, packages devcontainer-native-<version>-linux-x64.tar.gz, produces a SHA256 checksum, and creates a GitHub Release uploading both files using the gh CLI.
• Set the Rust package baseline to 0.0.1 by updating cmd/devcontainer-native/Cargo.toml and cmd/devcontainer-native/Cargo.lock so the repo starts from the requested initial version.

Testing

• Ran cargo build --manifest-path cmd/devcontainer-native/Cargo.toml locally and the build completed successfully.

---

Codex Task

[jooh]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d0792a6ccc

ℹ️ 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".

[chatgpt-codex-connector]

Add concurrency guard before deriving next tag

This workflow computes next_version from current tags without any concurrency key, so two push runs on main can execute in parallel, both pick the same latest_tag, and then race to publish the same release tag; one run will fail at release creation. GitHub Actions docs state the default behavior allows multiple workflow runs concurrently, so release numbering here is not safe under normal multi-push activity.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Fail when no new commits exist for release

gh release create is invoked without --fail-on-no-commits, and the command targets ${GITHUB_SHA}, so rerunning this workflow for an already released commit will still mint another patch tag/release for identical code. The gh release create manual explicitly says releases are created by default even when there are no new commits, which can produce duplicate releases.

Useful? React with 👍 / 👎.

[jooh]

@codex fix review suggestions

[chatgpt-codex-connector]

Summary

• Addressed the P1 race-condition feedback by adding a workflow-level concurrency guard so only one devcontainer-native-release run per ref can execute at a time when deriving/publishing the next tag.
• Addressed the P2 duplicate-release feedback by adding --fail-on-no-commits to gh release create, which prevents creating a new release when no new commits exist since the previous release.
• Committed the follow-up changes as 0f130e7 and created a new PR via the make_pr tool with a title/body summarizing the fixes on top of the original PR.

Testing

• ✅ git diff -- .github/workflows/devcontainer-native-release.yml
• ✅ git add .github/workflows/devcontainer-native-release.yml && git commit -m "Address release workflow review feedback"
• ⚠️ No local GitHub Actions runtime execution was performed (workflow behavior will be validated in CI on GitHub-hosted runners).

View task →