|
4 | 4 | push: |
5 | 5 | branches: |
6 | 6 | - main |
| 7 | + workflow_dispatch: |
7 | 8 |
|
8 | | -permissions: |
9 | | - contents: write |
10 | | - pull-requests: write |
| 9 | +permissions: {} |
11 | 10 |
|
12 | 11 | jobs: |
13 | 12 | release-please: |
14 | | - runs-on: ubuntu-latest |
15 | | - steps: |
16 | | - - name: Checkout repository |
17 | | - uses: actions/checkout@v6 |
18 | | - with: |
19 | | - fetch-depth: 0 |
20 | | - |
21 | | - - name: Run Release Please |
22 | | - id: release |
23 | | - uses: googleapis/release-please-action@v5 |
24 | | - with: |
25 | | - # This assumes you're using a personal access token stored as a secret |
26 | | - # If you want to use the default GITHUB_TOKEN, you can remove this line |
27 | | - token: ${{ secrets.GITHUB_TOKEN }} |
28 | | - |
29 | | - # Convert lightweight tag to annotated tag |
30 | | - # |
31 | | - # Why this is needed: |
32 | | - # - Release-please creates releases via GitHub's release API, which creates lightweight tags |
33 | | - # - We require annotated tags because: |
34 | | - # * git describe ignores lightweight tags by default (requires --tags flag) |
35 | | - # * Lightweight tags are not copied into forks |
36 | | - # * Annotated tags have proper metadata (creation date, tagger info, message) |
37 | | - # |
38 | | - # Why we do this after release creation: |
39 | | - # - We can't create the annotated tag before release-please runs because we don't know |
40 | | - # the version number until release-please determines it from conventional commits |
41 | | - # - The GitHub release API will use an existing tag if present (per the target_commitish |
42 | | - # parameter docs: "Unused if the Git tag already exists"), but release-please doesn't |
43 | | - # provide a way to hook into the process between version determination and release creation |
44 | | - # - Using skip-github-release has known issues and breaks release-please's workflow |
45 | | - # (see: https://github.com/googleapis/release-please/issues/1561) |
46 | | - # |
47 | | - # Race condition considerations: |
48 | | - # - There is a small window (milliseconds) between when the lightweight tag is created |
49 | | - # and when we convert it to annotated where someone could fetch the lightweight tag |
50 | | - # - In practice, this risk is acceptable because: |
51 | | - # * Most users interact with releases, not tags directly |
52 | | - # * The window is extremely brief |
53 | | - # * By the time manual tag fetches occur, the annotated version exists |
54 | | - # * The GitHub release points to the correct commit regardless of tag type |
55 | | - # |
56 | | - # Alternative approaches considered: |
57 | | - # - skip-github-release: Breaks release-please (Issue #1561) |
58 | | - # - Manual tag creation first: Impossible without knowing version number |
59 | | - # - Different release tooling: Would require migrating away from release-please |
60 | | - - name: Convert to annotated tag |
61 | | - if: ${{ steps.release.outputs.release_created }} |
62 | | - run: | |
63 | | - git config user.name "github-actions[bot]" |
64 | | - git config user.email "41898282+github-actions[bot]@users.noreply.github.com" |
65 | | - git fetch --tags |
66 | | - TAG_NAME="${{ steps.release.outputs.tag_name }}" |
67 | | - git tag -a -f -m "Release ${TAG_NAME}" "${TAG_NAME}" "${TAG_NAME}^{commit}" |
68 | | - git push -f origin "${TAG_NAME}" |
| 13 | + uses: opencoreemr/github-workflows-public/.github/workflows/release-please-reusable.yml@0.0.1 |
| 14 | + permissions: |
| 15 | + contents: write |
| 16 | + pull-requests: write |
0 commit comments