mitreattack-python/.github/workflows/release-and-publish.yml at main · mitre-attack/mitreattack-python · 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
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
name: Release and Publish

on:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  # Validate the squash merge commit message on pushes to main.
  # PR title validation is handled separately in pr-title.yml.
  commitlint:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v6
        with:
          fetch-depth: 2

      - name: Install uv
        uses: astral-sh/setup-uv@v7
        with:
          version: "latest"

      - name: Install Python and dependencies
        run: |
          uv python install 3.11
          uv sync --all-extras

      - name: Validate commit message
        run: uv run cz check --rev-range HEAD~1..HEAD

  release:
    needs: [commitlint]
    strategy:
      matrix:
        python-version: ["3.11"] # TODO see https://github.com/mitre-attack/mitreattack-python/issues/176
    runs-on: ubuntu-latest
    # The concurrency block prevents multiple release jobs from running simultaneously for the same branch.
    # This is particularly useful for releases since you typically want sequential deployments (finish
    # current release before starting next) rather than canceling in-progress releases or running them
    # in parallel.
    concurrency:
      # Creates a concurrency group keyed by workflow name + "release" + branch name (e.g., "Release and Publish-release-main")
      group: ${{ github.workflow }}-release-${{ github.ref_name }}
      # If a release is already running and a new push triggers another, the new job waits rather than canceling the running one
      # If you changed cancel-in-progress to true, a new push would cancel the currently running release job.
      cancel-in-progress: false

    permissions:
      contents: write

    steps:
      - name: Create GitHub App token
        id: app-token
        uses: actions/create-github-app-token@v3
        with:
          client-id: ${{ vars.ATTACK_AUTOBOT_CLIENT_ID }}
          private-key: ${{ secrets.ATTACK_AUTOBOT_PRIVATE_KEY }}

      # Note: We checkout the repository at the branch that triggered the workflow.
      # Python Semantic Release will automatically convert shallow clones to full clones
      # if needed to ensure proper history evaluation. However, we forcefully reset the
      # branch to the workflow sha because it is possible that the branch was updated
      # while the workflow was running, which prevents accidentally releasing un-evaluated
      # changes.
      - name: Setup | Checkout Repository on Release Branch
        uses: actions/checkout@v6
        with:
          fetch-depth: 0
          ref: ${{ github.ref_name }}
          token: ${{ steps.app-token.outputs.token }}
          persist-credentials: false

      - name: Setup | Force release branch to be at workflow sha
        run: |
          git reset --hard ${{ github.sha }}

      - name: Setup | Install uv
        uses: astral-sh/setup-uv@v7
        with:
          python-version: ${{ matrix.python-version }}

      - name: Setup | Install Python
        run: uv python install ${{ matrix.python-version }}

      - name: Setup | Install dependencies
        run: uv sync --all-extras

      - name: Semantic Release
        id: release
        uses: python-semantic-release/python-semantic-release@v10.5.3
        with:
          github_token: ${{ steps.app-token.outputs.token }}
          # NOTE: git_committer_name and git_committer_email are optional
          # We omit them because, if set, they must be associated with the provided token
          # and we don't really care to have a specific committer for automated releases.

      - name: Upload to GitHub Release Assets
        uses: python-semantic-release/publish-action@v10.5.3
        if: steps.release.outputs.released == 'true'
        with:
          github_token: ${{ steps.app-token.outputs.token }}
          tag: ${{ steps.release.outputs.tag }}

      - name: Upload distribution artifacts
        uses: actions/upload-artifact@v6
        if: steps.release.outputs.released == 'true'
        with:
          name: distribution-artifacts
          path: dist
          if-no-files-found: error

    outputs:
      released: ${{ steps.release.outputs.released || 'false' }}

  publish:
    # 1. Separate out the deploy step from the publish step to run each step at
    #    the least amount of token privilege
    # 2. Also, deployments can fail, and its better to have a separate job if you need to retry
    #    and it won't require reversing the release.
    needs: release
    if: needs.release.outputs.released == 'true'
    runs-on: ubuntu-latest
    environment:
      name: release
      url: https://pypi.org/p/mitreattack-python
    permissions:
      contents: read
      id-token: write  # IMPORTANT: this permission is mandatory for trusted publishing

    steps:
      - name: Download build artifacts
        uses: actions/download-artifact@v7
        id: artifact-download
        with:
          name: distribution-artifacts
          path: dist

      - name: Publish to PyPI
        uses: pypa/gh-action-pypi-publish@release/v1
        with:
          packages-dir: dist
          print-hash: true
          verbose: true