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.
Add theme, Python version, siteurl and feed_domain support to the
reusable GitHub Actions workflow for deploying a Pelican site to GitHub
Pages:
1. Add a new `theme` option to the workflow that callers can use to
specify an external theme to be checked out and used
2. Add a new `python` option to the workflow that callers can use to
specify the Python version, in case they need to build their site
with a particular version of Python
3. Pass `--extra-settings FEED_DOMAIN='"${{ steps.pages.outputs.base_url }}"'`
to the `pelican` command to set the value of Pelican's `FEED_DOMAIN`
setting for feed URLs.
4. Add a `feed_domain` input to the workflow so that users can override
the feed domain if they need to.
5. Add a `siteurl` input to the workflow so that users can override the
site URL if they need to.
6. Add a note to the docs about GitHub Pages generating http:// URLs for
https:// sites, and how to fix it
7. Some light editing of the docs for the workflow
Add a GitHub Actions workflow that users can use to publish their
Pelican sites to GitHub Pages by running `pelican` on GitHub Actions,
without having to run `pelican` locally and push the output directory to
a branch.
See: https://github.com/getpelican/pelican/discussions/3174
