Repository navigation
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.
madrob
reviewed
Oct 30, 2026
Comment on lines
186
to
+219
| 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} |
Contributor
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?
Contributor
Author
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?
Contributor
Contributor
Author
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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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