diff --git a/.github/workflows/release-please.yml b/.github/workflows/release-please.yml index 524be87..cc906cc 100644 --- a/.github/workflows/release-please.yml +++ b/.github/workflows/release-please.yml @@ -4,65 +4,13 @@ on: push: branches: - main + workflow_dispatch: -permissions: - contents: write - pull-requests: write +permissions: {} jobs: release-please: - runs-on: ubuntu-latest - steps: - - name: Checkout repository - uses: actions/checkout@v6 - with: - fetch-depth: 0 - - - name: Run Release Please - id: release - uses: googleapis/release-please-action@v5 - with: - # This assumes you're using a personal access token stored as a secret - # If you want to use the default GITHUB_TOKEN, you can remove this line - 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 - # - # Alternative approaches considered: - # - skip-github-release: Breaks release-please (Issue #1561) - # - Manual tag creation first: Impossible without knowing version number - # - Different release tooling: Would require migrating away from release-please - - 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}" + uses: opencoreemr/github-workflows-public/.github/workflows/release-please-reusable.yml@0.0.1 + permissions: + contents: write + pull-requests: write diff --git a/release-please-config.json b/release-please-config.json index 2174b69..b2a02e6 100644 --- a/release-please-config.json +++ b/release-please-config.json @@ -1,5 +1,6 @@ { "release-type": "simple", + "annotated-tag": true, "packages": { ".": { "package-name": "openemr-phpstan-rules",