mirror of
https://github.com/getpelican/pelican.git
synced 2025-10-15 20:28:56 +02:00
f9a0d9e56bCombine `build.yml` and `github_pages.yml` into a single workflow file. Having `build.yml` be a separate workflow file that `github_pages.yml` calls has two problems: 1. All the inputs (and their types, descriptions, defaults) have to be duplicated in the two workflow files. 2. The reference to `@main` in `uses: "getpelican/pelican/.github/workflows/build.yml@main"` in the `github_pages.yml` workflow makes development and testing awkward. For example let's say you want to send a pull request that contains changes to `build.yml` and that also requires changes to `github_pages.yml` at the same time. The problem is that the `github_pages.yml` on your PR branch will still contain the reference to `build.yml` `@main` so if you try to test the branch's version of `github_pages.yml` it'll call the version of `build.yml` from `main` not from the PR branch and will fail. This commit move the build job from `build.yml` into `github_pages.yml` but makes the deploy job optional: it adds a `deploy` input and will only run the deploy job if `deploy = true` is passed. Previously a user could test their build without deploying it by calling the separate `build.yml` workflow. Now they can do it by calling the `github_pages.yml` workflow and passing `deploy=false`. This commit also moves the `concurrency` stuff from the workflow level to the deploy level: it's okay to have multiple build jobs running concurrently, just not multiple deploy jobs. |
||
|---|---|---|
| .. | ||
| ISSUE_TEMPLATE | ||
| workflows | ||
| CODEOWNERS | ||
| dependabot.yml | ||
| FUNDING.yml | ||
| pull_request_template.md | ||
| stale.yml | ||