Skip to content

chore: update publish pipeline scripts to leverage GitHub rulesets#7676

Description

@janechu

馃檵 Feature Request

Replace the custom GitHub permission lookup used by checkchange with repository rulesets and a simple CI condition. This would preserve secure release bump PRs while reducing maintenance and failure points.

馃 Expected Behavior

  • Only authorized maintainers or a release GitHub App can create or update publish_* branches in microsoft/fast.
  • Beachball validation is skipped only for PRs originating from an authorized publish_* branch in the FAST repository.
  • Fork PRs named publish_* continue to run normal Beachball validation.
  • The validation workflow remains required and reports a successful skipped job for authorized bump PRs.

馃槸 Current Behavior

build/scripts/checkchange.mjs discovers the actor and token, queries the GitHub permissions API, handles authentication and network failures, and conditionally bypasses beachball check.

This is secure but introduces custom permission, token, timeout, and error-handling logic that must be maintained independently of GitHub鈥檚 repository controls.

馃拋 Possible Solution

  1. Add a GitHub ruleset targeting publish_* branches.
  2. Restrict branch creation and updates, with bypass permission limited to the release-maintainers team or release GitHub App.
  3. Replace the permission lookup with a CI condition that skips Beachball only when:
    • the PR head repository is microsoft/fast; and
    • the head branch matches the publish_* convention.
  4. Keep the workflow always triggered so its required status check is reported.
  5. Optionally require release-maintainer approval through CODEOWNERS or ruleset file-based reviewers.

馃敠 Context

Beachball鈥檚 bump command modifies versions and changelogs locally but does not provide a native bump-PR validation bypass. Some external conditional remains necessary.

GitHub rulesets already support branch-name targeting, restricted creation and updates, and team or GitHub App bypass lists. Using those controls would prevent contributors from spoofing an authorized release branch while eliminating most of the custom scripting.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions