Prior this commit, ${{ github.event.workflow_run.head_branch }} got
expanded in the bash script. A malicious actor could inject
an arbitrary shell script. Since this action has access to a token
with write rights the malicious actor can easily steal this token.
This commit moves the expansion into an env block where such an
injection cannot happen. This is the preferred way according to the
github docs:
https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-variable
Use the "Checks" workflow to trigger gitlab; this workflow should
be much quicker to complete and thus the gitlab ci will trigger
earlier leading to a more parallel ci run.
Sadly `github.event.workflow_run.pull_requests` is empty if the pull
request was opened from another fork. Use the sha to find an open PR,
otherwise assume it's a branch.
This workflow doesn't have access to the original pull request event
that resulted in this workflow being triggered.
Simply use `head_sha` which will contain the PR sha if it was triggered
by a PR's workflow, or the branch sha if it was triggered from a
branch's workflow.
The `workflow_run` event is triggered either when a workflow was
requested or complete (see `types`). We can use this event as a
trigger for the gitlab ci conditioning on a successful workflow
run of the main tests ("Tests" workflow). This will ensure that,
with outside contributor protection turned o, no secrets are
leaked via PRs from non-contributors, but also that gitlab ci is
run for those PRs once they were manually allowed to run.
The only downside is that now the gitlab ci will only run after
the main workflow ("Tests) has completed and thus serializing
both CI runs. OTOH gitlab CI is quite intense so maybe this is
not so bad after all. If in the future we want to parallelize
both CI runs we could have a third "precheck" condition with
maybe the spell checker and the pylint tests that the main tests
as well as the gitlab ci run depend on.
