Skip to content

GitHub settings cache prevents retry after branch protection skips a missing branch #123

Description

@tisonkun

Problem

When github.protected_branches includes a branch that does not yet exist, branch protection handling catches the 404 and continues. The enclosing GitHub feature then caches the complete GitHub YAML. Later default-branch pushes with unchanged GitHub settings return early, so protection is never retried after the branch is created.

This can affect generated branches such as asf-site.

Reproduction

  1. On the default branch, configure:

    github:
      protected_branches:
        main: {}
        asf-site: {}

    while only main exists.

  2. Push the configuration.

  3. Create asf-site afterward.

  4. Push another commit to the default branch without changing the github: block.

  5. Observe that asf-site remains unprotected.

The branch protection directive skips the missing branch:
https://github.com/apache/infrastructure-asfyaml/blob/main/asfyaml/feature/github/branch_protection.py#L119-L124

The outer GitHub feature then caches the YAML and skips later unchanged runs:
https://github.com/apache/infrastructure-asfyaml/blob/main/asfyaml/feature/github/__init__.py#L221-L232
https://github.com/apache/infrastructure-asfyaml/blob/main/asfyaml/feature/github/__init__.py#L254-L257

We observed this in apache/asyncband-site: the configuration was applied while only main existed, and the deployment workflow created asf-site 17 seconds later. The branch subsequently remained unprotected despite being declared in .asf.yaml.

Expected behavior

A retryable partial failure should not permanently mark the whole GitHub configuration as reconciled. The missing branch should be retried after it appears, or the pre-existing-branch requirement should be explicit and generated/future branches should be directed to rulesets.

Possible approaches

  • Avoid updating the GitHub settings cache when a directive reports a retryable partial failure.
  • Track pending directive/branch reconciliation separately and retry only those entries.
  • Reconcile protected branches on branch creation.
  • Document the current behavior and recommend rulesets for refs that may be created later.

Not caching the entire GitHub config after any partial failure is the smallest fix, but more granular pending state may avoid rerunning unrelated settings on every push.

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions