Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

GH Pages / Release workflow improvements #653

Merged
merged 3 commits into from
Feb 7, 2022
Merged

GH Pages / Release workflow improvements #653

merged 3 commits into from
Feb 7, 2022

Commits on Feb 7, 2022

  1. API docs: adjust script to use latest tag instead of release 

    The GitHub API unfortunately does not have a `/tags/latest` endpoint, so to get the latest tag, we need to get all tags, then sort them based on semantic version names and then get the latest from the stack.

This implements this in the script which updates the phpDocumentor configuration. The tag name is used as the API docs title in the generated docs.
    @jrfnl
    jrfnl committed Feb 7, 2022
    Configuration menu
    Copy the full SHA
    8952307 View commit details
    Browse the repository at this point in the history

  2. GH Actions: tweaks to the website update workflow 

    This commit makes various tweaks to the website update workflow based on the experiences round the 2.0.0 release:
* Run every time a tag is pushed.
    The previously included tag selection was only in place to prevent the script from running in case we'd still tag a 1.x release. As there is no intention to update the 1.x branch anymore, the tag selection can be removed.
* The `branches-ignore` addition is experimental.
    It is not unusual that in the ramp up to a release, a PR from `develop` to `stable` is created before all PRs for the release have been merged.
    Round the 2.0.0 release, this led to every PR merge which caused an update to the release PR to generate a new draft PR for the website update as the release contained the new workflow (which was therefore seen as "changed"), while that feature is only really intended for PRs to `develop`.
    Let's see if adding `stable` to `branch-ignore` for pull requests will prevent this in the future.
the PR, but after all changes have been made).
* Also made two minor tweaks to the pull request creation inputs.
* Workflows which create PRs do not trigger any other workflows which would normally run on a PR.
    This means that the `test-ghpages.yml` workflow in the `ghpages` branch is not triggered for the auto-generated PRs, while doing a test build to ensure there are no Jekyll errors when the website is deployed is kind of helpful.
    As this check only involves two steps, I'm duplicating these into this workflow to ensure the ghpages build test is still executed for the auto-generated PRs.
    @jrfnl
    jrfnl committed Feb 7, 2022
    Configuration menu
    Copy the full SHA
    8cda0f6 View commit details
    Browse the repository at this point in the history

  3. Release checklist: minor tweaks 

    While GH Pages does have access to the GitHub API during the site generation and deploy, the information it can access is limited.

I've verified that there is no access to the tags information. This means that for those places in the site which automatically update based on information from the GH API, we need to rely on release information, i.e. the release needs to have happened already for the information to be updated correctly.

This means that the merging of the GH Pages PR needs to happen after the release has been published.
This is now documented as such in the release checklist.

Ref: https://github.com/jekyll/github-metadata/blob/master/docs/site.github.md
    @jrfnl
    jrfnl committed Feb 7, 2022
    Configuration menu
    Copy the full SHA
    eb7b32b View commit details
    Browse the repository at this point in the history