Repository navigation
Add a workflows-scripts action that returns the scripts of the running workflow commit - #345
Conversation
…ing commit A caller that pins a reusable workflow to a release gets the workflow YAML from that release, but the scripts the YAML runs come from a separate checkout of this repository with no `ref:`, so they come from the default branch and a tag does not pin them. The new composite action locates the scripts and configuration files through `github.action_path`, which GitHub resolves for a `$/` reference to this repository at the commit of the running workflow. An optional `copy_into_workspace` input copies the scripts into the workspace, for consumers that only see the workspace, and the action returns the scripts path in POSIX, Windows and workspace-relative forms.
`package_test.yml`, `toolchain_matrix.yml`, `benchmarks.yml` and `execute_matrix.yml` resolved their scripts with two steps that checked out the default branch of `workflows_repository`, so a release tag did not pin them. The two inputs existed only to point at a fork, which can instead be tested by calling its workflow at its own ref. Replaced those steps with `uses: $/.github/actions/workflows-scripts`. The generator jobs run `generate-matrix.swift` straight from the action's directory. The `execute_matrix.yml` jobs ask for the copy in the workspace, so the Linux container mount, the Windows prefix translation and the FreeBSD VM's rsync of the workspace keep working without changes to the runner scripts. Removed `workflows_repository` and `workflows_ref` and their forwarding, and updated the FreeBSD test for the new relative directory.
Each soundness job that ran a script or read a default configuration file checked out `swiftlang/github-workflows` from the default branch, so a release of `soundness.yml` did not pin them. Replaced the checkout and the script-root step in eight jobs with `uses: $/.github/actions/workflows-scripts` and read the scripts and configs from its outputs. The jobs use the action's own directory, with no copy, since none of them runs the scripts in another file system.
Requirement 3 of the architecture document said the scripts are checked out explicitly, which no longer describes how they are found. The document also never said what `$/` means, what the `workflows-scripts` action returns, or how to test a change now that `workflows_repository` and `workflows_ref` are gone. Rewrote requirement 3 to state only the requirement, that the scripts come from the commit of the running workflow, and moved the mechanism into a "How workflows get their scripts" section. It explains `$/`, tabulates the action's input and outputs, notes that `execute_matrix.yml` copies the scripts for containers and the FreeBSD VM after the checkout, and says a change is tested by calling the workflow at its own branch or fork ref. Listed the action among the components.
| docs-check: | ||
| name: Documentation check | ||
| if: ${{ inputs.docs_check_enabled }} | ||
| runs-on: ubuntu-latest | ||
| container: | ||
| image: ${{ inputs.docs_check_container_image }} | ||
| timeout-minutes: 20 | ||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v7 | ||
| with: | ||
| persist-credentials: false | ||
| submodules: true | ||
| - name: Checkout swiftlang/github-workflows repository | ||
| if: ${{ github.repository != 'swiftlang/github-workflows' }} | ||
| uses: actions/checkout@v7 | ||
| with: | ||
| repository: swiftlang/github-workflows | ||
| path: github-workflows | ||
| - name: Determine script-root path | ||
| id: script_path | ||
| run: | | ||
| if [ "${{ github.repository }}" = "swiftlang/github-workflows" ]; then | ||
| echo "root=$GITHUB_WORKSPACE" >> $GITHUB_OUTPUT | ||
| else | ||
| echo "root=$GITHUB_WORKSPACE/github-workflows" >> $GITHUB_OUTPUT | ||
| fi | ||
| - name: Locate the workflows scripts | ||
| id: workflows_scripts | ||
| uses: $/.github/actions/workflows-scripts | ||
| - name: Run documentation check | ||
| env: | ||
| ADDITIONAL_DOCC_ARGUMENTS: ${{ inputs.docs_check_additional_arguments }} | ||
| DOCC_ANALYZE: ${{ inputs.docs_check_analyze }} | ||
| DOCS_TARGETS: ${{ inputs.docs_check_targets}} | ||
| SCRIPT_ROOT: ${{ steps.script_path.outputs.root }} | ||
| SCRIPTS_DIRECTORY: ${{ steps.workflows_scripts.outputs.scripts_directory }} | ||
| run: | | ||
| set -x | ||
| ${{ inputs.linux_pre_build_command }} | ||
| analyze_arg="" | ||
| doc_target_arg="" | ||
| if [ "${DOCS_TARGETS}" != "" ] ; then | ||
| doc_target_arg="--doc-targets ${DOCS_TARGETS}" | ||
| fi | ||
| if [ "${DOCC_ANALYZE}" != "true" ]; then | ||
| analyze_arg="--no-analyze" | ||
| fi | ||
| "${SCRIPT_ROOT}/.github/workflows/scripts/check-docs.sh" ${analyze_arg} ${doc_target_arg} --additional-docc-arguments ${ADDITIONAL_DOCC_ARGUMENTS} | ||
| "${SCRIPTS_DIRECTORY}/check-docs.sh" ${analyze_arg} ${doc_target_arg} --additional-docc-arguments ${ADDITIONAL_DOCC_ARGUMENTS} |
There was a problem hiding this comment.
I think what we really want is to convert this run block into its own action and then this all simplifies to uses: $/.github/actions/docs-check. Actions should bundle all of their configuration files so the same works for e.g. flake8. However, there's also a trap where if we make structural changes then it breaks anybody who is using an older version and expects to be able to clone the scripts from main. I think that means we need to do it in two PRs across two versions?
There was a problem hiding this comment.
Doing this would mean we'd need many actions though right? One for each run block we remove?
There was a problem hiding this comment.
Yep, which get called from the single composite workflow.
There was a problem hiding this comment.
I think this approach is a simpler route, much of the infrastructure is unchanged - there's just a utility which prepares the scripts for it
There was a problem hiding this comment.
Overall I agree that we should probably have actions for each those. Not only actions here actually but public Github actions that are generally usable on the marketplace for common things like doc check, API break check etc. To keep this PR focused though I think this already provides meaningful value without also changing the scripts to actions.
As far as I can tell things broke because the scripts moved locations in #220, and up until this change everyone gets their scripts from |
A caller that pins a reusable workflow to a release gets the workflow YAML from that release, but the scripts the YAML runs come from a separate checkout of this repository with no
ref:, so they come from the default branch and a tag does not pin them.The new composite action locates the scripts and configuration files through
github.action_path, which GitHub resolves for a$/reference to this repository at the commit of the running workflow. An optionalcopy_into_workspaceinput copies the scripts into the workspace, for consumers that only see the workspace, and the action returns the scripts path in POSIX, Windows and workspace-relative forms.This PR also adopts this change for
soundness.yml,package_test.yml,toolchain_matrix.yml,benchmarks.ymlandexecute_matrix.yml. (It leavesswift_package_test.ymlunchanged.)This should resolve #334