ci: add semantic-release workflow + minimal test perms - #3
Merged
Conversation
README markets `uses: skyhook-io/read-config@v1` but nothing was creating that tag. Add the same `codfish/semantic-release-action@v4` release workflow used by skyhook-io/kustomize-edit and skyhook-io/kustomize-deploy so pushes to main mint v1.x.y tags + a sliding v1 ref automatically. Also add a minimal `permissions: contents: read` block to test.yml — sibling workflows already gate perms explicitly; the test workflow had no token-reaching steps but defaulting to whatever GITHUB_TOKEN scope is configured at the repo level isn't great hygiene.
…ile_path Previously the action hardcoded "." as the fallback for build_context when the YAML didn't supply one, but emitted empty for dockerfile_path. That asymmetry pushed defaulting logic onto every consumer's workflow (`|| 'Dockerfile'` sprinkled everywhere) and made the "default" value an action implementation detail rather than a caller choice. Two new optional inputs let the caller own the fallback policy: default_dockerfile_path - emitted when YAML doesn't supply dockerfilePath default_build_context - emitted when YAML doesn't supply buildContext Rule (now symmetric for both fields): YAML wins when the config is readable AND the service exists AND the field is non-empty. In every other case (config missing, service missing, field absent/null/empty) the corresponding default_* input is emitted. Defaults are empty strings so a caller without an opinion still gets a clean empty signal — same back-compat behavior for the missing-config/ missing-service paths, just symmetric across the two build-tool fields. README's behavior matrix rewritten to document the single rule. Tests extended to cover both code paths (with and without default_* inputs) plus the YAML-wins-over-default precedence. CI smoke job exercises three new scenarios (no caller default, caller default for absent field, caller default on missing service).
Bugbot caught this: codfish/semantic-release-action invokes semantic-release with whatever release config it finds in the repo. Without a .releaserc the default plugin list includes @semantic-release/npm, which fails on this repo (no package.json), and the additional-packages install of semantic-release-github-actions-tags doesn't register it either. Mirror the .releaserc.json that skyhook-io/kustomize-edit and skyhook-io/kustomize-deploy use: - commit-analyzer + release-notes-generator: pick version + write notes - github: cut the GH Release - semantic-release-github-actions-tags: mint the v1 / v1.x.y sliding refs - NO @semantic-release/npm
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit f0352bc. Configure here.
The macOS shell-tests job in CI hung for 6 hours on tests/parse_test.sh. Root cause was the heredoc delimiter generator in parse.sh: tr -dc 'a-f0-9' </dev/urandom | head -c 16 `tr` reading from `/dev/urandom` produces unbounded output. `head -c 16` closes its stdin after 16 bytes, which on Linux promptly delivers SIGPIPE to tr. On macOS bash the SIGPIPE doesn't always propagate before tr buffers another write, leaving tr (and the whole `$()` substitution) blocked indefinitely. Linux + Linux smoke jobs ran the same script in ~6 seconds; macOS hit the 6h job timeout. Switched to bash's built-in $RANDOM + $$ - no external process, no pipe SIGPIPE dance, identical uniqueness guarantee for the script's needs (small number of outputs per run). Fully portable across Linux + macOS. Also added a `timeout-minutes: 10` cap to both CI jobs. The script should finish in seconds; capping well below the 6h platform default means any future hang fails fast instead of burning runner hours. Tests still pass locally on macOS with the new delimiter.
Cursor Bugbot flagged that actions/checkout@v4 defaults to a shallow
fetch (fetch-depth: 1), but semantic-release walks the full commit
history to find the previous release tag + analyze commits since.
Without fetch-depth: 0 the first run could pick the wrong base and
later runs could mis-version or skip releases entirely.
The other Bugbot finding (".releaserc missing") was already addressed
by f0352bc — the .releaserc.json is present with an explicit plugin
list that excludes @semantic-release/npm and includes
semantic-release-github-actions-tags. The latest review flagging it
appears to be operating on a stale snapshot.
|
🎉 This PR is included in version 1.1.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Summary
uses: skyhook-io/read-config@v1but nothing creates that tag. Sibling actions (kustomize-edit, kustomize-deploy) usecodfish/semantic-release-action@v4onpush: mainto mintv1.x.ytags + a slidingv1ref. Copying that workflow verbatim so consumers can pin@v1as documented.permissions: contents: readtotest.yml. No token-using steps run today, but explicit minimal perms are the project pattern.What's NOT in this PR
I reviewed the action and surfaced a few behavior/interface notes (asymmetric defaults for
build_contextvsdockerfile_path, no source-path-relative Dockerfile default, nofail_if_missingopt-in). Per discussion these are deliberate design choices — empty outputs are the "couldn't read, you decide" signal — so leaving them out of scope.Test plan
bash tests/parse_test.shpasses locally (47 assertions).bash tests/metadata_test.shpasses locally.v1.x.y+v1on the next push to main.Note
Medium Risk
Changing
build_contextfrom implicit"."to empty unless callers passdefault_build_contextcan break existing workflows that relied on the old default; release workflow also needs correct commit conventions and token permissions on first run.Overview
Adds automated releases via a new
Releaseworkflow and.releaserc.json(semantic-release onmain, deep checkout, GitHub Action tag plugin) so@v1style pins can be published. CI gets explicit read permissions on tests, 10-minute job timeouts, and broader smoke coverage for the new inputs.Breaking behavior change for Docker outputs:
build_contextanddockerfile_pathno longer use action-side defaults (notably"."for missingbuildContext). New optional inputsdefault_build_contextanddefault_dockerfile_pathare echoed whenever YAML does not supply a non-empty value—including missing config or service. YAML still wins when the service exists and the field is set.parse.shfixes a macOS CI hang in heredoc delimiter generation by replacingtr/headon/dev/urandomwith bash$RANDOM/$$. README documents the fallback rule and updated behavior matrix; unit and smoke tests assert empty vs caller-supplied defaults.Reviewed by Cursor Bugbot for commit d818357. Bugbot is set up for automated code reviews on this repo. Configure here.