bib2graph/.github/workflows/release-please.yml at dev · complexluise/bib2graph · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
name: release-please

# Automatiza el versionado/release a partir de Conventional Commits (VERSIONING.md):
# abre/actualiza un PR de release con el bump de versión en pyproject.toml y la
# sección nueva del CHANGELOG; al mergearlo, crea el tag vX.Y.Z y el GitHub Release,
# y dispara la publicación a PyPI (job `publish`, gateado por el output release_created).

on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    outputs:
      release_created: ${{ steps.release.outputs.release_created }}
    steps:
      - uses: googleapis/release-please-action@v4
        id: release
        with:
          # target-branch FIJO a main: release-please gestiona SIEMPRE main aunque
          # la rama por defecto del repo sea `dev`. Sin esto, su default es la rama
          # por defecto del repo (dev) y abre los release PRs contra dev por error.
          target-branch: main
          # Si existe el secret RELEASE_PLEASE_TOKEN (un PAT), el PR de release lo
          # crea ese token y SÍ dispara el CI (los commits del GITHUB_TOKEN no
          # disparan workflows). Sin el secret, cae al GITHUB_TOKEN y el PR de
          # release se mergea con bypass de admin. Ver VERSIONING.md.
          token: ${{ secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }}
          config-file: release-please-config.json
          manifest-file: .release-please-manifest.json

  # Publica a PyPI SOLO cuando release-please efectivamente cortó un Release.
  # Corre en el MISMO workflow run (el push a main al mergear el release PR), así que
  # NO depende del evento `on: release` (que el GITHUB_TOKEN no dispararía). Reusa
  # publish-pypi.yml (workflow_call). El fallback manual sigue en ese workflow.
  publish:
    needs: release-please
    if: ${{ needs.release-please.outputs.release_created == 'true' }}
    permissions:
      contents: read
      id-token: write # OIDC del trusted publishing — lo debe otorgar el caller
    uses: ./.github/workflows/publish-pypi.yml

  # Back-merge AUTOMÁTICO main → dev tras cada release: sincroniza el bump de versión
  # + CHANGELOG a dev para que las ramas no diverjan. Merge+push DIRECTO, sin PR ni
  # gate de CI (decisión del PO: que sea automático; si hay conflicto el job falla y
  # se resuelve a mano). Requiere que el actor pueda pushear a `dev` protegido: o se
  # permite a github-actions[bot] saltar la protección de dev, o se setea el secret
  # RELEASE_PLEASE_TOKEN (un PAT).
  back-merge:
    needs: release-please
    if: ${{ needs.release-please.outputs.release_created == 'true' }}
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v5
        with:
          ref: dev
          fetch-depth: 0
          token: ${{ secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }}
      - name: Merge main → dev y push
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git fetch origin main
          git merge origin/main --no-edit
          git push origin HEAD:dev