feat: Refactor workflows

[stevehipwell]

Resolves #2425

This PR requires the following changes before it should be merged.

• Add a ruleset to restrict the creation of branches with the pattern release-v* to maintainers - done
• Add ruleset for the default branch and release branches to manage spec - done
• Add ruleset to restrict the creation of tags with the v* pattern to maintainers (or only admins?)
• Create release environment and protect it to tags with the pattern v* - done
• Move release secrets to release environment
• Replace project workflow with native project support or add environment and move secret? - done
• Create acctest label - done
• Create acctest-dotcom & acctest-ghes environments and require that they be approved by maintainers - done and done
• Add DOTCOM_TEST_USER_TOKEN to acctest-dotcom environment (created a new token - we'll need to verify if the fine grained settings are correct).
• Add GHES_TEST_USER_TOKEN to acctest-ghes environment (created a new token - we'll need to verify if the fine grained settings are correct).
• Add GHES_TEST_SERVER_HOST to vars

Post Merge

• Update ruleset for the default branch and release branches to require the CI & CodeQL workflows to have been run
• Require tags to be created from releasable branches via required check

Post Next Release

• Update documentation to cover validating artifact attestation

---

Before the change?

• Workflows aren't following best practices for security hardening
• There isn't a way to run acceptance tests from a fork PR
• The release process isn't attesting the binaries

After the change?

• Workflows have been hardened
• Automation can be run from forked repos if a label has been added (repo write) and an environment is approved (repo maintain)
• Release binaries are attested
• Release SBOMs are generated
• CI only runs on fixed branches?

Pull request checklist

• Schema migrations have been created if needed (example)
• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

[nickfloyd]

Looks great! I love the collapse of jobs ❤️ - approving pending completion / this coming out of draft status.

[stevehipwell]

Looks great! I love the collapse of jobs ❤️ - approving pending completion / this coming out of draft status.

@nickfloyd the draft status is required until the repo level changes are made to keep secrets isolated from pull request target workflows.

[ViacheslavKudinov]

Added some comments

[nickfloyd]

@stevehipwell I am pretty sure we're going to need an action to support the following:
Add ruleset to restrict the creation of tags with the v* pattern to the default branch (main) or branches with the pattern release-v*

Using:

on:
  push:
    tags:
      - 'v*'

Through rulesets I belive I can only restrict who can create version tags and not necessarily where - I might be either missing the whole picture of what you're thinking or you might know a way we could via rulesets. Let me know.

[nickfloyd]

RE: Replace project workflow with native project support or add environment and move secret?

I'm assuming that you are referring to this workflow. That can be removed completely - given we no longer use that board. I've enabled the auto-add on our project board.

[stevehipwell]

Add ruleset to restrict the creation of tags with the v* pattern to the default branch (main) or branches with the pattern release-v*

@nickfloyd I'm not actually sure what I meant when I wrote that. I suspect I got ahead of myself, as it'd require a check that only runs on the relevant branches to be run and used as a constraint. Shall we leave that for a future change?

I'm just about to update the acceptance tests to run on the releasable branches to catch anything that can't be tested on the PR. That said it may be worth making the default ruleset use the following settings?

[stevehipwell]

@nickfloyd this is currently pretty good once the final repo changes are made. Would you like me to add a check in the PR workflow to detect if there are any unexpected secrets and error out so they can't be leaked by TF code?

[nickfloyd]

@nickfloyd this is currently pretty good once the final repo changes are made. Would you like me to add a check in the PR workflow to detect if there are any unexpected secrets and error out so they can't be leaked by TF code?

Yes please. I'll try to get the remaining items wrapped.

[stevehipwell]

@nickfloyd I've added the guard clause for the secrets, this allows the defined secrets and any secrets with the TEST_ prefix (I'll update the acceptance tests PR to make sure secrets are only being created using this prefix). The defined secrets default to the token for the tests but this can be overridden by setting the relevant variable to the allowed secrets sorted and joined with a ,.

• DOTCOM_ACCEPTANCE_TESTS_ALLOWED_SECRETS
• GHES_ACCEPTANCE_TESTS_ALLOWED_SECRETS