diff --git a/.github/workflows/README.md b/.github/workflows/README.md index a57a31c0..59a48610 100644 --- a/.github/workflows/README.md +++ b/.github/workflows/README.md @@ -1,21 +1,6 @@ -# Carpentries Workflows +# Workflow Documentation -This directory contains workflows to be used for Lessons using the Carpentries Workbench lesson infrastructure. - -The three `docker-` workflows build lessons and maintain packages. -The workflows run using the [workbench-docker](https://github.com/carpentries/workbench-docker) container. -This container comprises prebuilt and installed dependencies of the core Workbench packages, i.e. sandpaper, pegboard and varnish. - -Two `update-` workflows handle: - - checking for new renv packages and creating a Pull Request (PR) when a renv.lock file updates (`update-cache.yaml`) - - checking for updated versions of these workflow files (`update-workflows.yaml`) - -The rest of the `pr-` workflows handle pull request management via base GitHub Actions. - -For Carpentries Core Curriculum lessons across our lesson programmes, maintenance of these workflows should be minimal. -For your own lesson repositories, it is important to understand the different workflows and what they do. - -## Managing Updates +## Managing Workflow Updates By using prebuilt Docker containers that are managed by the Carpentries core Workbench maintainers, these workflows are designed to be rarely updated. @@ -47,19 +32,30 @@ $ git commit -m "Manual update to docker workflows" $ git push origin main ``` -This will automatically start the "01 Maintain: Build and Deploy Site" workflow. +> [!NOTE] +> For non-renv lessons, this is all the setup you need! +> +> For renv-enabled lessons: +> - Cancel any "01 Maintain: Build and Deploy Site" workflow currently running +> - Run the "02 Maintain: Check for Updated Packages" workflow and merge any PR opened to update the renv lockfile +> - This should automatically run the "03 Maintain: Apply Package Cache" workflow to install packages and build the cache +> - A successful cache buid should then trigger the "01 Maintain: Build and Deploy Site" workflow -This will be the extent of requirements for non-renv lessons. +### Updating using GitHub -#### Lessons that use Rmd and {renv} +#### Official lessons -For renv-enabled lessons: -- Cancel the "01 Maintain: Build and Deploy Site" run that automatically started following the push to main -- Run the "02 Maintain: Check for Updated Packages" -- Run the "03 Maintain: Apply Package Cache" -- Run the "01 Maintain: Build and Deploy Site" +"Official" lessons are those in the lesson program repositories, Incubator, or Lab. +They need no extra setup as this is all managed for you as part of the Carpentries GitHub organisations. -### Updating using GitHub +To update the workflows, either: +- wait for the scheduled run of the "04 Maintain: Update Workflow Files" at approximately midnight every Tuesday +- go to the Actions tab on GitHub, click "04 Maintain: Update Workflow Files" on the left, then "Run Workflow" on the right + +Once complete, this will raise a PR with any changes to the workflows that are needed. +If you are happy with the changes made, you can merge the PR into your lesson repository. + +#### Your own lessons This presumes you: - already have a lesson repository available on GitHub @@ -74,34 +70,19 @@ Once set up, run the "04 Maintain: Update Workflow Files" (`update-workflows.yam This will raise a PR with any changes to the workflows that are needed. If you are happy with the changes made, you can merge the PR into your lesson repository. -## Lesson Builds and Deployment - -### 01 Maintain: Build and Deploy Site (docker_build_deploy.yaml) - -This is the main workflow that you will encounter most often. - -It will only act on the main branch of the lesson repository. - -This workflow does the following: - 1. checks out the lesson - 2. provisions the following resources - - the Workbench Docker container - - lesson dependencies if needed (stored in a cache) - 3. builds the lesson via `sandpaper:::ci_deploy()` -If your lesson contains rendered content using RMarkdown and/or any associated R package dependencies, you will need to generate and apply the renv cache. -Please read the [Caching](#caching) section below. +## Package Caches for RMarkdown Lessons -#### Caching +In summary, generating a reusable package cache is achieved by running the "02 Maintain: Check for Updated Packages" workflow, and then the "03 Maintain: Apply Package Cache" workflow. > [!NOTE] > Caching is only relevant for lessons that use Rmd files and renv to manage R packages. > If you are building basic markdown documents, caching will not apply to you, and the only > workflow that needs to be run is "01 Maintain: Build and Deploy Site". -In summary, generating a reusable package cache is achieved by running the "02 Maintain: Check for Updated Packages" workflow, and then the "03 Maintain: Apply Package Cache" workflow. +### Caching -These workflows are separated to ensure that once you have a successful build with a working renv cache, this cache is stored within GitHub's infrastructure, and will be reused by the Workbench Docker container. +The two cache management workflows are separated to ensure that once you have a successful build with a working renv cache, this cache is stored and will be reused by the Workbench Docker container. This means that lesson builds will be faster once an renv cache is created and reused by the Docker container. Another major bonus of this setup is that you can keep using this cache indefinitely to build your lesson. @@ -123,18 +104,14 @@ There are times when you may want to go back to a previous renv package cache fi - if you run "02 Maintain: Check for Updated Packages" and "03 Maintain: Apply Package Cache" and the cache generation fails for some reason - if there is a new R package that produces incorrect or broken lesson output -To choose a previous cache file version for your builds, go to the Actions tab, and click Caches in the left hand pane. - -Cache files should have the following name format: +Cache files will have the following name format, where IMAGE is the workbench-docker image version, and HASHSUM is the `renv.lock` lockfile MD5 hash: ``` - OS HASHSUM -[ | ] [ | ] -Linux--renv-2e499eb706112971b2cffceb49b55a6efe49f3ed75cd6579b10ff224489daca4 +IMAGE HASHSUM +[ | ] [ | ] +v0.2.4_renv-2e499eb706112971b2cffceb49b55a6efe49f3ed75cd6579b10ff224489daca4 ``` -Once you have 2 or more cache files, you can choose which one you want to use. - Copy the hashsum part of the desired cache file you want to use, e.g. `2e499eb706112971b2cffceb49b55a6efe49f3ed75cd6579b10ff224489daca4`. Then either: @@ -145,137 +122,112 @@ Then either: If you have no caches listed, make sure to run the "02 Maintain: Check for Updated Packages" and "03 Maintain: Apply Package Cache" to create a new renv cache file. -## Updates - -### Setup Information - -These workflows run on a mix of schedules, automatic triggers, and at the maintainer's request. -Because they create pull requests that update workflows/require the downstream actions to run, -they need a special repository/organization secret token called -`SANDPAPER_WORKFLOW` and it must have the `public_repo` and `workflow` scope. - -This can be an individual user token, OR it can be a trusted bot account. If you -have a repository in one of the official Carpentries organisations, then you do not -need to worry about this token being present because the Carpentries Core Team -will take care of supplying this token. - -If you want to use your personal account: you can go to - -to create a token. Once you have created your token, you should copy it to your -clipboard and then go to your repository's settings > secrets > actions and -create or edit the `SANDPAPER_WORKFLOW` secret, pasting in the generated token. - -If you do not specify your token correctly, the runs will not fail and they will -give you instructions to provide the token for your repository. +> [!NOTE] +> If you are maintaining an official lesson, caches are saved in an AWS S3 bucket owned by the Carpentries. +> Once a successful cache has been saved, these will be listed in the outputs of the "01 Maintain: Build and Deploy Site" workflow. +> +> If you are developing a lesson in your own repository, caches are saved on GitHub. +> You can see available caches by going to the Actions tab, and clicking Caches on the left hand side. -### "02 Maintain: Check for Updated Packages" (update-cache.yaml) -For lessons that have generated content, we use {renv} to ensure that the output -is stable. This is controlled by a single lockfile which documents the packages -needed for the lesson and the version numbers. This workflow is skipped in -lessons that do not have generated content. +## User Settings -Packages are frequently updated, fixing bugs or introducing new features. It's a -good idea to make sure these packages can be both: updated periodically, or; or left -static to ensure consistent lesson builds. +Input level variables are documented in the `carpentries/actions` repository READMEs for each composite action. -The update cache workflow will do this by: -- checking repositories for updates -- updating the renv lockfile -- summarising the updated packages and their versions in a branch called `updates/packages` -- creating a pull request with _only the renv lockfile changed_ +Specific repository level variables can be set that will force particular options across all workflow runs. -From here, the markdown documents will be rebuilt and you can inspect what has -changed based on how the packages have updated. +### 01 Maintain: Build and Deploy Site (docker_build_deploy.yaml) -If all steps pass in this workflow, you can safely merge the PR that is raised. -Once the PR is merged, the "03 Maintain: Apply Package Cache" workflow will run -automatically. +Repository-level variables for this workflow are: +- WORKBENCH_TAG + - The workbench-docker release version to use for a given build + - This can be set to a specific version number to force all builds to use a given container version + - Default is unset or `latest` +- BUILD_RESET + - Force a reset of previously build markdown files + - Setting this variable value to `true` will force sandpaper to delete any previously build markdown files + - Default is unset or `false` +- AUTO_MERGE_WORKBENCH_VERSION_UPDATE + - Control merge behaviour of the workbench-docker version update PR + - When a new workbench Docker image version is detected, usually after a sandpaper, varnish, or pegboard update, its version number will be incremented + - If a newer version is available, a PR will be auto-generated that updates the `.github/workbench-docker-version.txt` file, and this PR will be auto-merged + - To not auto-merge this PR and to choose when to update the Docker version used, set this to `false`. + - Default is unset or `true` +- LANG_CODE + - Two-letter language code that triggers the use of Joel Nitta's {dovetail} package for lesson translation + - This is used in the internationalisation repos of the main Carpentry lesson programs + - Default is unset or `''` + +### 02 Maintain: Check for Updated Packages (update-cache.yaml) + +Repository-level variables for this workflow are: +- LOCKFILE_CACHE_GEN + - Passed to the `generate-cache` input of the [update-lockfile](https://github.com/carpentries/actions/tree/main/update-lockfile) action + - A temporary renv cache is generated when this workflow runs + - If this option is set to `false`, no temporary cache will be generated + - Default is `true` +- FORCE_RENV_INIT + - Passed to the `force-renv-init` input of the [update-lockfile](https://github.com/carpentries/actions/tree/main/update-lockfile) action + - renv initialises a cache based on a given lockfile + - If this lockfile is particularly old or packages have broken/unresolvable dependencies, then builds will fail + - If this option is set to `true`, a full renv reinitialisation will occur, "wiping the slate clean" + - This option is useful if you're using Bioconductor packages which often break when new Bioconductor releases happen + - Default is `false` +- UPDATE_PACKAGES + - Passed to the `update` input of the [update-lockfile](https://github.com/carpentries/actions/tree/main/update-lockfile) action + - If set to `false` only package hydration will happen and no package update checks will occur + - Default is `true` ### 03 Maintain: Apply Package Cache (docker_apply_cache.yaml) -This workflow takes the updated lockfile produced in "02 Maintain: Check for Updated Packages" -and uses it to produce a cached file stored within GitHub's infrastructure. - -This cached file can then be reused repeatedly by the "01 Maintain: Build and Deploy Site" -workflow. - -This workflow is run automatically when the PR generated by "02 Maintain: Check for Updated Packages" -is closed and merged. - -You would only ever need to run this workflow manually: -- if your cache gets removed by GitHub due to age or non-use -- if your cache file contains packages that cannot be used by a Workbench Docker container's newer R version - -### "04 Maintain: Update Workflow Files" (update-workflows.yaml) - -The {sandpaper} repository was designed to do as much as possible to separate -the tools from the content. For local builds, this is absolutely true as you -can develop and build lessons without any GitHub workflows. When it comes to -workflow files on GitHub itself for managed builds online, the workflows must -live inside the lesson repository. +Repository-level variables for this workflow are: +- WORKBENCH_TAG + - The workbench-docker release version to use for a given build + - This can be set to a specific version number to force all builds to use a given container version + - Default is unset or `latest` -This workflow ensures that the workflow files are up-to-date. It downloads the -`update-workflows.sh` script from GitHub and runs it. The script will do the -following: -1. check the recorded version of sandpaper against the current version on GitHub -2. update the files if there is a difference in versions +### 04 Maintain: Update Workflow Files (update-workflows.yaml) -After the files are updated, and if there are any changes, they are pushed to a -branch called `update/workflows` and a pull request is created. Maintainers are -encouraged to review the changes and accept the pull request if the outputs -are okay. +There are no repository variables for this workflow. -This update is run weekly or on demand. ## Pull Request and Review Management -Because our lessons execute code, pull requests are a secruity risk for any -lesson and thus have security measures associted with them. **Do not merge any -pull requests that do not pass checks and do not have bots commented on them.** +Because our lessons execute code, pull requests are a security risk for any lesson and thus have security measures associted with them. +**Do not merge any pull requests that do not pass checks and do not have bots commented on them.** -This series of workflows all go together and are described in the following -diagram and the below sections: +This series of workflows all go together and are described in the following diagram and the below sections: ![Graph representation of a pull request](https://carpentries.github.io/sandpaper/articles/img/pr-flow.dot.svg) ### Pre Flight Pull Request Validation (pr-preflight.yaml) -This workflow runs every time a pull request is created and its purpose is to -validate that the pull request is okay to run. This means the following things: +This workflow runs every time a pull request is created and its purpose is to validate that the pull request is okay to run. +This means the following things: 1. The pull request does not contain modified workflow files -2. If the pull request contains modified workflow files, it does not contain - modified content files (such as a situation where @carpentries-bot will - make an automated pull request) -3. The pull request does not contain an invalid commit hash (e.g. from a fork - that was made before a lesson was transitioned from styles to use the - workbench). +2. If the pull request contains modified workflow files, it does not contain modified content files + (such as a situation where @carpentries-bot will make an automated pull request) +3. The pull request does not contain an invalid commit hash + (e.g. from a fork that was made before a lesson was transitioned from styles to use the Workbench). -Once the checks are finished, a comment is issued to the pull request, which -will allow maintainers to determine if it is safe to run the -"Receive Pull Request" workflow from new contributors. +Once the checks are finished, a comment is issued to the pull request, which will allow maintainers to determine if it is safe to run the "Receive Pull Request" workflow from new contributors. ### Receive Pull Request (docker_pr_receive.yaml) -**Note of caution:** This workflow runs arbitrary code by anyone who creates a -pull request. GitHub has safeguarded the token used in this workflow to have no -privileges in the repository, but we have taken precautions to protect against -spoofing. +**Note of caution:** This workflow runs arbitrary code by anyone who creates a pull request. +GitHub has safeguarded the token used in this workflow to have no privileges in the repository, but we have taken precautions to protect against spoofing. -This workflow is triggered with every push to a pull request. If this workflow -is already running and a new push is sent to the pull request, the workflow -running from the previous push will be cancelled and a new workflow run will be -started. +This workflow is triggered with every push to a pull request. +If this workflow is already running and a new push is sent to the pull request, the workflow running from the previous push will be cancelled and a new workflow run will be started. -The first step of this workflow is to check if it is valid (e.g. that no -workflow files have been modified). If there are workflow files that have been -modified, a comment is made that indicates that the workflow is not run. If -both a workflow file and lesson content is modified, an error will occurr. +The first step of this workflow is to check if it is valid (e.g. that no workflow files have been modified): +- If there are workflow files that have been modified, a comment is made that indicates that the workflow will not continue. +- If both a workflow file and lesson content is modified, an error will occur and the workflow will not continue. -The second step (if valid) is to build the generated content from the pull -request. This builds the content and uploads three artifacts: +The second step (if valid) is to build the generated content from the pull request. +This builds the content and uploads three artifacts: 1. The pull request number (pr) 2. A summary of changes after the rendering process (diff) @@ -288,25 +240,21 @@ The artifacts produced are used by the "Comment on Pull Request" workflow. This workflow is triggered if the `docker_pr_receive.yaml` workflow is successful. The steps in this workflow are: -1. Test if the workflow is valid and comment the validity of the workflow to the - pull request. -2. If it is valid: create an orphan branch with two commits: the current state - of the repository and the proposed changes. +1. Test if the workflow is valid and comment the validity of the workflow to the pull request. +2. If it is valid: create an orphan branch with two commits: the current state of the repository and the proposed changes. 3. If it is valid: update the pull request comment with the summary of changes -Importantly: if the pull request is invalid, the branch is not created so any -malicious code is not published. +Importantly: if the pull request is invalid, the branch is not created so any malicious code is not published. -From here, the maintainer can request changes from the author and eventually -either merge or reject the PR. When this happens, if the PR was valid, the -preview branch needs to be deleted. +From here, the maintainer can request changes from the author and eventually either merge or reject the PR. +When this happens, if the PR was valid, the preview branch needs to be deleted. ### Send Close PR Signal (pr-close-signal.yaml) -Triggered any time a pull request is closed. This emits an artifact that is the -pull request number for the next action +Triggered any time a pull request is closed. +This emits an artifact that is the pull request number for the next action. ### Remove Pull Request Branch (pr-post-remove-branch.yaml) -Tiggered by `pr-close-signal.yaml`. This removes the temporary branch associated with -the pull request (if it was created). +Tiggered by `pr-close-signal.yaml`. +This removes the temporary branch associated with the pull request (if it was created). diff --git a/.github/workflows/docker_apply_cache.yaml b/.github/workflows/docker_apply_cache.yaml index 0cb66370..2c3a3bce 100644 --- a/.github/workflows/docker_apply_cache.yaml +++ b/.github/workflows/docker_apply_cache.yaml @@ -208,20 +208,22 @@ jobs: restore-keys: ${{ github.repository }}/${{ steps.wb-vers.outputs.container-version }}_renv- - trigger-build-deploy: - name: "Trigger Build and Deploy Workflow" + record-cache-result: + name: "Record Caching Status" runs-on: ubuntu-latest - needs: update-renv-cache - if: | - needs.update-renv-cache.result == 'success' || - needs.check-renv.outputs.renv-cache-available == 'true' + needs: [check-renv, update-renv-cache] + if: always() + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} steps: - - uses: actions/checkout@v4 + - name: "Record cache result" - - name: "Trigger Build and Deploy Workflow" - env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | - gh workflow run docker_build_deploy.yaml --ref main + echo "${{ needs.update-renv-cache.result == 'success' || needs.check-renv.outputs.renv-cache-available == 'true' || 'false' }}" > ${{ github.workspace }}/apply-cache-result shell: bash - continue-on-error: true + + - name: "Upload cache result" + uses: actions/upload-artifact@v4 + with: + name: apply-cache-result + path: ${{ github.workspace }}/apply-cache-result diff --git a/.github/workflows/docker_build_deploy.yaml b/.github/workflows/docker_build_deploy.yaml index 27343955..01719206 100644 --- a/.github/workflows/docker_build_deploy.yaml +++ b/.github/workflows/docker_build_deploy.yaml @@ -4,11 +4,16 @@ on: push: branches: - 'main' + - 'l10n_main' paths-ignore: - '.github/workflows/**.yaml' - '.github/workbench-docker-version.txt' schedule: - cron: '0 0 * * 2' + workflow_run: + workflows: ["03 Maintain: Apply Package Cache"] + types: + - completed workflow_dispatch: inputs: name: @@ -72,7 +77,6 @@ jobs: runs-on: ubuntu-latest needs: preflight if: | - always() && needs.preflight.outputs.do-build == 'true' && needs.preflight.outputs.workbench-update != 'true' env: @@ -129,6 +133,7 @@ jobs: with: reset: ${{ vars.BUILD_RESET || github.event.inputs.reset || 'false' }} skip-manage-deps: ${{ github.event.inputs.force-skip-manage-deps == 'true' || steps.build-container-deps.outputs.renv-cache-available || steps.build-container-deps.outputs.backup-cache-used || 'false' }} + lang-code: ${{ vars.LANG_CODE || '' }} update-container-version: name: "Update container version used" diff --git a/.github/workflows/docker_pr_receive.yaml b/.github/workflows/docker_pr_receive.yaml index 12b16bf7..3d01d9dc 100644 --- a/.github/workflows/docker_pr_receive.yaml +++ b/.github/workflows/docker_pr_receive.yaml @@ -19,7 +19,6 @@ permissions: pull-requests: write jobs: - preflight: name: "Preflight: md-outputs exists?" runs-on: ubuntu-latest @@ -49,7 +48,9 @@ jobs: test-pr: name: "Record PR number" - if: ${{ github.event.action != 'closed' }} && ${{ needs.preflight.outputs.branch-exists == 'true' }} + if: | + github.event.action != 'closed' && + needs.preflight.outputs.branch-exists == 'true' runs-on: ubuntu-latest needs: preflight outputs: @@ -135,6 +136,7 @@ jobs: checks: write contents: write pages: write + id-token: write container: image: ghcr.io/carpentries/workbench-docker:${{ vars.WORKBENCH_TAG || 'latest' }} env: @@ -279,24 +281,3 @@ jobs: - name: "Teardown" run: sandpaper::reset_site() shell: Rscript {0} - - pr-checks: - name: "Trigger PR Checks?" - needs: - - test-pr - - build-md-source - runs-on: ubuntu-latest - if: needs.test-pr.outputs.is_valid == 'true' - permissions: - actions: write - checks: write - steps: - - name: "Checkout Lesson" - uses: actions/checkout@v4 - - - name: "Trigger PR Checks" - env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - run: | - gh workflow run pr-comment.yaml --ref main --field workflow_id=${{ github.run_id }} - shell: bash diff --git a/.github/workflows/pr-comment.yaml b/.github/workflows/pr-comment.yaml index cbf0e2b2..7614abd0 100644 --- a/.github/workflows/pr-comment.yaml +++ b/.github/workflows/pr-comment.yaml @@ -1,14 +1,10 @@ name: "Bot: Comment on the Pull Request" description: "Comment on the pull request with the results of the markdown generation" on: - workflow_dispatch: - inputs: - workflow_id: - required: true - -concurrency: - group: pr-${{ github.event.workflow_run.pull_requests[0].number }} - cancel-in-progress: true + workflow_run: + workflows: ["Bot: Receive Pull Request"] + types: + - completed jobs: # Pull requests are valid if: @@ -18,16 +14,6 @@ jobs: test-pr: name: "Test if pull request is valid" runs-on: ubuntu-latest - if: > - github.event_name == 'workflow_dispatch' || - ( - github.event_name == 'workflow_run' && - ( - github.event.workflow_run.event == 'pull_request' || - github.event.workflow_run.event == 'workflow_dispatch' - ) && - github.event.workflow_run.conclusion == 'success' - ) outputs: is_valid: ${{ steps.check-pr.outputs.VALID }} payload: ${{ steps.check-pr.outputs.payload }} @@ -38,7 +24,7 @@ jobs: id: dl uses: carpentries/actions/download-workflow-artifact@main with: - run: ${{ github.event.workflow_run.id || inputs.workflow_id }} + run: ${{ github.event.workflow_run.id }} name: 'pr' - name: "Get PR Number" @@ -79,11 +65,9 @@ jobs: - name: "Skip checks for Workbench version file updates" if: steps.changed-files.outputs.only_version_file == 'true' - env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | - echo "Only workbench-docker-version.txt changed, skipping preflight checks and running cache update" - gh workflow run update-cache.yaml --ref main + echo "# 🔧 Wait for Next Cache Update #" + echo "Only workbench-docker-version.txt changed." exit 0 shell: bash @@ -138,7 +122,7 @@ jobs: id: dl uses: carpentries/actions/download-workflow-artifact@main with: - run: ${{ github.event.workflow_run.id || inputs.workflow_id }} + run: ${{ github.event.workflow_run.id }} name: 'built' - if: steps.dl.outputs.success == 'true' @@ -177,7 +161,7 @@ jobs: id: dl uses: carpentries/actions/download-workflow-artifact@main with: - run: ${{ github.event.workflow_run.id || inputs.workflow_id }} + run: ${{ github.event.workflow_run.id }} name: 'diff' - if: steps.dl.outputs.success == 'true' @@ -210,7 +194,7 @@ jobs: id: dl uses: carpentries/actions/download-workflow-artifact@main with: - run: ${{ github.event.workflow_run.id || inputs.workflow_id }} + run: ${{ github.event.workflow_run.id }} name: 'built' - name: "Alert if spoofed" diff --git a/.github/workflows/sandpaper-version.txt b/.github/workflows/sandpaper-version.txt deleted file mode 100644 index 0cc98846..00000000 --- a/.github/workflows/sandpaper-version.txt +++ /dev/null @@ -1 +0,0 @@ -0.18.4 diff --git a/.github/workflows/update-cache.yaml b/.github/workflows/update-cache.yaml index 27b6d1cd..ce318f6f 100644 --- a/.github/workflows/update-cache.yaml +++ b/.github/workflows/update-cache.yaml @@ -154,7 +154,7 @@ jobs: steps.update.outputs.n > 0 uses: carpentries/create-pull-request@main with: - token: ${{ steps.set-pat.outputs.pat || secrets.SANDPAPER_WORKFLOW || secrets.GITHUB_TOKEN }} + token: ${{ steps.set-pat.outputs.pat || secrets.SANDPAPER_WORKFLOW }} delete-branch: true branch: "update/packages" commit-message: "[actions] update ${{ steps.update.outputs.n }} packages" @@ -188,13 +188,3 @@ jobs: run: | echo "No updates needed, skipping PR creation" shell: bash - - # thanks @Bisaloo! - https://github.com/carpentries/sandpaper/issues/646#issuecomment-2829578435 - # only trigger checks manually if the validate-token step had no valid AWS or SANDPAPER_WORKFLOW token - - name: "Trigger checks" - if: | - steps.cpr.outputs.pull-request-number != '' && - steps.validate-org-workflow.outputs.is_valid != 'true' - run: | - gh workflow run docker_pr_receive.yaml --field pr_number=${{ steps.cpr.outputs.pull-request-number }} - shell: bash diff --git a/.github/workflows/update-workflows.yaml b/.github/workflows/update-workflows.yaml index 09ec1b63..e57927bb 100644 --- a/.github/workflows/update-workflows.yaml +++ b/.github/workflows/update-workflows.yaml @@ -1,5 +1,6 @@ name: "04 Maintain: Update Workflow Files" description: "Update workflow files from the carpentries/sandpaper repository" + on: schedule: - cron: '0 0 * * 2' @@ -9,10 +10,10 @@ on: description: 'Who triggered this build (enter github username to tag yourself)?' required: true default: 'weekly run' - tarball: - description: 'Absolute URL to the desired sandpaper repo tarball' + version: + description: 'Workflows version number (e.g. 0.0.1), branch name (e.g. main), or "latest"' required: false - default: '' + default: 'latest' clean: description: 'Workflow files/file extensions to clean (no wildcards, enter "" for none)' required: false @@ -88,7 +89,7 @@ jobs: if: ${{ steps.validate-token.outputs.wf == 'true' }} uses: carpentries/actions/update-workflows@main with: - repo: ${{ github.event.inputs.tarball || 'https://carpentries.r-universe.dev' }} + version: ${{ github.event.inputs.version || 'latest' }} clean: ${{ github.event.inputs.clean || '.yaml' }} - name: Create Pull Request diff --git a/.github/workflows/workflows-version.txt b/.github/workflows/workflows-version.txt new file mode 100644 index 00000000..3eefcb9d --- /dev/null +++ b/.github/workflows/workflows-version.txt @@ -0,0 +1 @@ +1.0.0