build: minor updates in CI/CD workflow files

- polish code comments
- wrap long lines

Signed-off-by: Lukas Puehringer <[email protected]>

Author: lukpueh

.github/workflows/cd.yml

@@ -1,7 +1,7 @@
 name: CD
 concurrency: cd
 
-# Trigger workflow on completed CI (further checks below)
+# Trigger workflow on any completed CI (see further checks below)
 on:
   workflow_run:
     workflows: [CI]
@@ -11,18 +11,11 @@ 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.
+    # Skip unless CI was successful and ran on release tag, a ref starting with 'v'.
+    # NOTE: We assume CI does not trigger on branches that start with 'v' (see #1961)
+    if: >-
+      github.event.workflow_run.conclusion == 'success' &&
+      startsWith(github.event.workflow_run.head_branch, 'v')
     outputs:
       release_id: ${{ steps.gh-release.outputs.id }}
     steps:
@@ -52,13 +45,10 @@ jobs:
           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
+        # NOTE: The GitHub release page contains the release artifacts too, but using
+        # GitHub upload/download actions seems robuster: there is no need to compute
+        # download URLs and tampering with artifacts between jobs is more limited.
         with:
           name: build-artifacts
           path: dist
@@ -90,5 +80,8 @@ jobs:
               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.'
+              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.'
             })

.github/workflows/ci.yml

@@ -1,11 +1,11 @@
 name: CI
 
 on:
+  # NOTE: CD relies on this configuration (see #1961)
   push:
     branches:
       - develop
     tags:
-      # TODO: Should we restrict to vX.Y.Z tags?
       - v*
 
   pull_request: