Sean Hammond f9a0d9e56b Combine build.yml and github_pages.yml ... Combine `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.		2024-10-14 17:20:25 +01:00
..
github_pages.yml	Combine build.yml and github_pages.yml	2024-10-14 17:20:25 +01:00
main.yml	Rename default branch to main	2024-06-25 11:33:28 +02:00