Skip to content

Prepare 1.0.0 release: release workflow, action updates - #94

Merged
dvejsada merged 1 commit into
masterfrom
release/1.0.0
Oct 4, 2026
Merged

dvejsada merged 1 commit into
masterfrom
release/1.0.0

Conversation

@dvejsada

@dvejsada dvejsada commented Oct 4, 2026

Copy link
Copy Markdown
Owner

Summary

  • New release.yaml: runs when a release is published (or manually for an existing tag). It checks the tag against the manifest.json version, runs the tests, builds rohlikcz.zip with the integration files at the archive root (what hacs.json zip_release expects) and attaches it to the release.
  • Bump actions/checkout to v7 and actions/setup-python to v7.
  • CI workflows get read-only token permissions; hassfest can be run manually.
  • Add Dependabot config for GitHub Actions (monthly).
  • Bump version to 1.0.0; drop beta-specific notes from the README and update manual install steps to use rohlikcz.zip.

Release steps after merge

Publish release v1.0.0 from master (not a pre-release). The workflow attaches the ZIP.

🤖 Generated with Claude Code

- Add release workflow that checks the tag against the manifest version,
  runs the tests and attaches rohlikcz.zip to the published release
- Bump actions/checkout to v7 and actions/setup-python to v7
- Give CI workflows read-only token permissions; allow manual hassfest runs
- Add Dependabot config to keep GitHub Actions up to date
- Bump version to 1.0.0 and drop beta notes from the README

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@dvejsada

dvejsada commented Oct 4, 2026

Copy link
Copy Markdown
Owner Author

@claude please review this PR. Focus on correctness of the new release workflow (tag/version check, ZIP layout for HACS zip_release, upload step) and the action version bumps.

@claude

claude Bot commented Oct 4, 2026 •

Copy link
Copy Markdown

Claude finished @dvejsada's task in 30s —— View job


Review of PR #94: 1.0.0 release workflow

The release workflow looks correct overall. I found no blocking issues. The main thing to confirm before merging is the @v7 action versions.

I read the diff and the repo files. I did not run the workflow, and I could not check the action versions against GitHub from this environment.

release.yaml

  • Tag/version check: this works. TAG falls back from the release event to the dispatch input. It reaches the shell only through env, so there is no script injection from the input. ${TAG#v} handles both v1.0.0 and 1.0.0, and jq -r is available on ubuntu-latest. The check also lets a pre-release tag such as v1.0.0-beta5 through if the manifest matches, which seems right.
  • Checkout ref: ref: ${{ env.TAG }} is valid because the env context is available in step with. It builds from the tagged commit rather than master, which is what you want.
  • ZIP layout: this matches hacs.json (zip_release: true, filename: rohlikcz.zip). working-directory: custom_components/rohlikcz followed by zip -r ... . puts manifest.json, __init__.py and translations/ at the archive root, and HACS extracts it into custom_components/rohlikcz/. The __pycache__ cleanup happens before zipping, and the unzip -l step makes the layout visible in the logs. zip is preinstalled on the runner image.
  • Upload: gh release upload "$TAG" rohlikcz.zip --clobber --repo "$GITHUB_REPOSITORY" works with contents: write and GH_TOKEN. --clobber makes re-runs through workflow_dispatch safe.

Minor points, not blockers:

  1. Gap before the asset exists. The workflow triggers on published, so the release is live for a minute or two before the ZIP is attached. A HACS update check in that window would hit a missing asset. This is usually harmless. The workflow can't avoid it without a draft-based flow.
  2. A failed check leaves a bare release. If the version check or tests fail, the release stays published with no ZIP. The remedy is to fix the problem, re-tag if needed, and re-run through workflow_dispatch. The "Release steps after merge" section of the PR description could say so.
  3. A missing tag fails late. For workflow_dispatch with a typo'd tag, checkout fails with a ref error. That's acceptable, since the error message is clear enough.
  4. Duplicated test setup. The test setup repeats test.yaml. A reusable workflow would avoid the duplication, but it's not needed.

Action version bumps

  • actions/checkout@v7 and actions/setup-python@v7: I could not confirm these tags exist, and the latest majors I know of are lower. If either tag doesn't exist, every workflow fails at "Set up job". Please check that both tags exist and are the intended majors, for example with git ls-remote --tags https://github.com/actions/checkout. The PR's own CI run would also catch this, so check that it's green before merging.
  • The bumps are applied consistently in claude.yml, hassfest.yaml, test.yaml and release.yaml. validate.yaml was not changed. Beyond the version check above, the version bumps look fine.
  • home-assistant/actions/hassfest@master is unpinned. That was already the case and is out of scope here.

Other changes

  • Permissions: the read-only permissions: contents: read on the CI workflows is good. release.yaml correctly has contents: write.
  • Dependabot: the monthly GitHub Actions config is fine.
  • README: the manual install steps match the ZIP layout. /releases/latest skips pre-releases, so it points at the stable release.
  • Manifest: the version is now 1.0.0, which satisfies the tag check for v1.0.0.

@dvejsada
dvejsada merged commit b572505 into master Oct 4, 2026
4 of 5 checks passed
@dvejsada
dvejsada deleted the release/1.0.0 branch October 4, 2026 09:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant