python-tuf/.github/workflows/cd.yml
Lukas Puehringer a1a71c11a1 build: update CI/CD workflow to run in series
- Change CI workflow to also run on push to (release) tag
- Change CD workflow to run on successful CI run, and only if a
  (release) tag push triggered the CI

NOTE: Unfortunately the setup is not very robust
      (see code comment in cd.yml)

Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
2022-04-07 12:15:39 +02:00

94 lines
3.9 KiB
YAML

name: CD
concurrency: cd
# Trigger workflow on completed CI (further checks below)
on:
workflow_run:
workflows: [CI]
types: [completed]
jobs:
build:
name: Build
runs-on: ubuntu-latest
# Skip unless CI was successful and ran on a ref starting with 'v' (release tag)
if: ${{ github.event.workflow_run.conclusion == 'success' && startsWith(github.event.workflow_run.head_branch, 'v') }}
# NOTE: This works because we currently only trigger CI on a push to the 'develop'
# branch or a 'v*'-tag, but it seems rather brittle.
# Unfortunately, there is not much more info we get from the CI workflow
# ('workflow_run') than the ref name. No ref, ref_type, etc., so we don't even know
# if a tag or a branch was pushed. :(
# See https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_run
# NOTE: (2) An alternative solution might be to restructure workflows, so that all
# test logic from 'ci.yml' is moved to a separate workflow file '_test.yml', that
# can be included in both CI (triggered on push to 'develop'-branch) and CD
# (triggered on push to 'v*'-tag) workflows.
outputs:
release_id: ${{ steps.gh-release.outputs.id }}
steps:
- name: Checkout release tag
uses: actions/checkout@a12a3943b4bdde767164f792f33f40b04645d846
with:
ref: ${{ github.event.workflow_run.head_branch }}
- name: Set up Python
uses: actions/setup-python@0ebf233433c08fb9061af664d501c3f3ff0e9e20
with:
python-version: '3.x'
- name: Install build dependency
run: python3 -m pip install --upgrade pip build
- name: Build binary wheel and source tarball
run: python3 -m build --sdist --wheel --outdir dist/ .
- id: gh-release
name: Publish GitHub release candiate
uses: softprops/action-gh-release@1e07f4398721186383de40550babbdf2b84acfc5
with:
name: ${{ github.event.workflow_run.head_branch }}-rc
tag_name: ${{ github.event.workflow_run.head_branch }}
body: "Release waiting for review..."
files: dist/*
- name: Store build artifacts
# NOTE: The release job could download the assets from the GitHub release page,
# published in the previous step. But using the GitHub upload/download actions
# seems more robust as there is no need to compute download URLs.
# NOTE: (2) action-gh-release returns download URLSs as output, which could be
# propagated to next job along with release_id (see above)
# https://github.com/softprops/action-gh-release#outputs
uses: actions/upload-artifact@6673cd052c4cd6fcf4b4e6e60ea986c889389535
with:
name: build-artifacts
path: dist
release:
name: Release
runs-on: ubuntu-latest
needs: build
environment: release
steps:
- name: Fetch build artifacts
uses: actions/download-artifact@fb598a63ae348fa914e94cd0ff38f362e927b741
with:
name: build-artifacts
path: dist
- name: Publish binary wheel and source tarball on PyPI
uses: pypa/gh-action-pypi-publish@717ba43cfbb0387f6ce311b169a825772f54d295
with:
user: __token__
password: ${{ secrets.PYPI_API_TOKEN }}
- name: Finalize GitHub release
uses: actions/github-script@9ac08808f993958e9de277fe43a64532a609130e
with:
script: |
await github.rest.repos.updateRelease({
owner: context.repo.owner,
repo: context.repo.repo,
release_id: '${{ needs.build.outputs.release_id }}',
name: '${{ github.event.workflow_run.head_branch }}',
body: 'See [CHANGELOG.md](https://github.com/'+ context.repo.owner +'/'+ context.repo.repo +'/blob/${{ github.event.workflow_run.head_branch }}/docs/CHANGELOG.md) for details.'
})