Skip to content

ci: use github token with release-please - #41

Merged
fstagni merged 3 commits into
DIRACGrid:mainfrom
aldbr:ci/release-please-github-token
Nov 12, 2026
Merged

fstagni merged 3 commits into
DIRACGrid:mainfrom
aldbr:ci/release-please-github-token

Conversation

@aldbr

@aldbr aldbr commented Nov 11, 2026

Copy link
Copy Markdown
Contributor

No description provided.

Drop MY_RELEASE_PLEASE_TOKEN, a long-lived token readable from any branch that
could push tags and therefore publish to PyPI. release-please now runs as the
first job of deployment.yml with the job token, and the build/publish jobs run
when it reports release_created, building the new tag (hatch-vcs unchanged).
This is the layout diracx-web already uses: a single workflow, because nothing
done with GITHUB_TOKEN (including the release tag) starts another workflow.

The workflow now only runs on pushes to the default branch, so the pypi
environment must allow that branch instead of v* tags.

Assisted-by: Claude:claude-opus-5-5
- concurrency group so two quick merges cannot race to create the same
  release (queued runs are kept, one may wait on pypi approval)
- workflow_dispatch with a tag input to rebuild and publish an existing
  release when the publish failed after the release was created
- drop the explicit token input (it is the action's default)
- install only build and readme_renderer; python -m build gets hatchling
  and hatch-vcs from build-system.requires in its isolated env
- rename the workflow to "Release"; it now runs on every push to main

Assisted-by: Claude:claude-opus-5-5
Assisted-by: Claude:claude-opus-5-5
@fstagni
fstagni merged commit e01eec5 into DIRACGrid:main Nov 12, 2026
5 checks passed
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.

2 participants