Skip to content

chore(main): release 0.9.0 (#22) #11

chore(main): release 0.9.0 (#22)

chore(main): release 0.9.0 (#22) #11

name: Release Please
on:
push:
branches:
- main
workflow_dispatch:
permissions:
contents: write
pull-requests: write
jobs:
release-please:
runs-on: ubuntu-latest
outputs:
release_created: ${{ steps.release.outputs.release_created }}
tag_name: ${{ steps.release.outputs.tag_name }}
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Run Release Please
id: release
uses: googleapis/release-please-action@v4
with:
token: ${{ secrets.GITHUB_TOKEN }}
# Convert lightweight tag to annotated tag
#
# Why this is needed:
# - Release-please creates releases via GitHub's release API, which creates lightweight tags
# - We require annotated tags because:
# * git describe ignores lightweight tags by default (requires --tags flag)
# * Lightweight tags are not copied into forks
# * Annotated tags have proper metadata (creation date, tagger info, message)
#
# Why we do this after release creation:
# - We can't create the annotated tag before release-please runs because we don't know
# the version number until release-please determines it from conventional commits
# - The GitHub release API will use an existing tag if present (per the target_commitish
# parameter docs: "Unused if the Git tag already exists"), but release-please doesn't
# provide a way to hook into the process between version determination and release creation
# - Using skip-github-release has known issues and breaks release-please's workflow
# (see: https://github.com/googleapis/release-please/issues/1561)
#
# Race condition considerations:
# - There is a small window (milliseconds) between when the lightweight tag is created
# and when we convert it to annotated where someone could fetch the lightweight tag
# - In practice, this risk is acceptable because:
# * Most users interact with releases, not tags directly
# * The window is extremely brief
# * By the time manual tag fetches occur, the annotated version exists
# * The GitHub release points to the correct commit regardless of tag type
- name: Convert to annotated tag
if: ${{ steps.release.outputs.release_created }}
run: |
git config user.name "github-actions[bot]"
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
git fetch --tags
TAG_NAME="${{ steps.release.outputs.tag_name }}"
git tag -a -f -m "Release ${TAG_NAME}" "${TAG_NAME}" "${TAG_NAME}^{commit}"
git push -f origin "${TAG_NAME}"
# Build and attach PHAR to release
# This is called directly because release events from GITHUB_TOKEN
# don't trigger other workflows (GitHub security feature)
build-phar:
needs: release-please
if: ${{ needs.release-please.outputs.release_created == 'true' }}
uses: ./.github/workflows/build-phar.yml
with:
tag_name: ${{ needs.release-please.outputs.tag_name }}