Github Workflow can't push to protected gh-pages branch

[jacobwolfaws]

Originally brought up here: https://kubernetes.slack.com/archives/C01672LSZL0/p1677773943548989

The helm release github workflow can't push to the gh-pages branch of this repo: https://github.com/jacobwolfaws/aws-file-cache-csi-driver . The way most kubernetes repositories resolve this is by removing branch protections and the easycla check for this branch, but there are some legal concerns for using unprotected branches w/o CLA check. Ideally, an org-level mitigation would be taken that:

1. allows for github workflows to push to select protected branches
2. once 1 is complete, find all unprotected branches and bring them back into compliance

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[jacobwolfaws]

/remove-lifecycle stale

[nikhita]

@caniszczyk Please advise if we can get a CLA exception for the github-actions bot to push to the gh-pages branch. Here's more context on the issue we face:

• Some GitHub actions require the github-actions bot to push to certain branches, commonly the gh-pages branch.
• If branch protection is enabled on these branches, then the bot will fail to push because it hasn't signed the CLA.
• We would like a CLA exception to allow commits from the github-actions bot in cases where both of these conditions are satisfied:
  1. commits created by the github-actions bot
  2. pushed only to the gh-pages branch

Additional context

Precedence

The project has encountered similar scenarios in the past and has disabled branch protection to allow commits by the github-actions bot - kubernetes/test-infra#23384. We agree that these changes should not have occured in the first place but this also means that we have precedent...

Similar issues in other projects

A similar issue was encountered in OpenTelemetry - open-telemetry/community#809. OTel folks asked for the github-actions bot to be added to the EasyCLA allowlist but were told that this was not possible due to open-telemetry/community#809 (comment).

The workaround suggested was to register a user in github, give that user permission, and generate a token to perform actions on behalf of that user. CNCF can then allowlist the user as a bot user - open-telemetry/community#809 (comment).

Long term solution

As mentioned above, our long term solution is to do something similar and leverage a prowjob. @MadhavJivrajani did an extensive investigation on how to achieve this but it will require additional work - https://gist.github.com/MadhavJivrajani/e80469715aaff79b362651dd8d1aca97.

We'd like to move to GitHub actions as much as possible. Not having an exception blocks us from achieving that goal.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[jacobwolfaws]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[XudongLiuHarold]

/remove-lifecycle stale

We also face the same issue in cloud-provider-vsphere repo, IMO, it is better we specifically allow github-actions bot to push to gh-pages instead of removing gh-pages from protect branches.