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

jacobwolfaws commented 1 year ago

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:

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

k8s-triage-robot commented 1 year ago

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 commented 1 year ago

/remove-lifecycle stale

nikhita commented 1 year ago

@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 - https://github.com/kubernetes/test-infra/pull/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 - https://github.com/open-telemetry/community/issues/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 https://github.com/open-telemetry/community/issues/809#issuecomment-905869941.

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 - https://github.com/open-telemetry/community/issues/809#issuecomment-1016522419.

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 commented 6 months ago

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 commented 5 months ago

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 commented 5 months ago

/remove-lifecycle rotten

k8s-triage-robot commented 2 months ago

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 commented 1 month ago

/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.

kubernetes / org