Grant kick off / restart github actions workflow permissions to members

[serathius]

What would you like to be added?

Follow up to #15593 (comment)

Need to figure out how to do that, one way would be to adopt K8s bot but that comes with it's own downsides.

Why is this needed?

Would be great reward

[chaochn47]

Followed up in https://github.com/orgs/community/discussions/49688 to see how other projects solve this problem.

[gusmith-ambiata]

Hi @chaochn47 , I've been pinged in the discussion you mentioned.
Sorry I cannot share the project I'm working on which is private.
But what we did was to use a workflow issue trigger, i.e. our workflow gets triggered on issue creation. We decided to use filter on the issue name to know if the workflow should actually do something, e.g. if the newly created issue's name starts with [#run-my-workflow] then the workflow's first step is to assess if it should actually run. The following steps are conditional based on the output of the first step.
Then, to give feedback to the users, I'm using gh for example gh issue comment ${ISSUE_NUMBER} --body "I will be your bot for today."
Not necessarily working example (poorly copied/pasted removing a lot of things to be able to share it) :

name: "Workflow triggered by issue creation/re-opening"
on:
  issues:
    types: [opened, reopened]

env:
  ISSUE_NUMBER: ${{ github.event.issue.number }}
  CURRENT_BUILD_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}

jobs:
  my-job:
    if: ${{ !github.event.issue.pull_request }} # I don't want it triggered on PRs
    steps:
    - name: Checkout
      uses: actions/checkout@v2
    - name: Bot present itself
      run: |
            gh issue comment ${ISSUE_NUMBER} --body "I will be your scanner bot for today, here is your [build url](${CURRENT_BUILD_URL})."
    - name: Select if continue
      id: continue_selector
      env:
        TITLE: ${{ github.event.issue.title }}
      run: |
        if [[ ${TITLE} =~ "^[#run-my-workflow](.*)$" ]]; then
          echo "We will continue the workflow"
          echo "continue=true" >> ${GITHUB_OUTPUT}
        else
          echo "We will not continue the workflow"
          echo "continue=false" >> ${GITHUB_OUTPUT}
        fi
    - name: If to continue
      if: ${{ steps.continue_selector.outputs.continue }}
      run: |
         gh issue comment ${ISSUE_NUMBER} --body "Yeah, I have to run"

So in a nutshell, this workflow is triggered everytime an issue is created, but some steps are ran only if it should based on a condition on the issue name. And the issue could also be closed automatically after the workflow has ran.
You could also filter using labels or other things. Your call, and there are a lot of possibilities :)

[chaochn47]

Thanks @gusmith-ambiata for providing such detailed instructions!! I will give it a shot in my personal public repository.

Use cases:

• First time contributor requires maintainers' approval to kick off CI (I assume it's a burden on maintainers and most importantly it is not necessary)
• Active contributors needs to restart workflows or restart failed jobs in a specific workflow.

The input will be issue title like Start workflow action {{run id}} {{job id}}. Job id is optional ideally.

Are GITHUB_TOKEN permissions permissive or restricted in etcd-io/etcd? The former has actions write permissions.

ref.

1. https://cli.github.com/manual/gh_run_rerun
2. https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

[chaochn47]

@serathius I think get a minimal example working. chaochn47/etcd-issues#2 (comment). It would require workflows have write permissions to the repository.

Could you please share your thoughts if this workaround sounds good to you?

/cc @ahrtr

[serathius]

Sorry but I should not give write permissions to workflows. This causes a security issue as we have custom workers for ARM that would become a security concern.

[gusmith-ambiata]

Just for documentation, you may be able to assign permissions to the token in the workflow:
https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs#overview

[chaochn47]

Thanks @gusmith-ambiata for the constructive input!!

We could set the default permissions to workflows to "restricted" one and only configure a job in a workflow (for example rerun-failed-test-job) with the least privileged permissions.

    permissions:
      issues: write
      actions: write

https://github.com/chaochn47/etcd-issues/blob/main/.github/workflows/rerun-failed-job.yaml#L14-L16

This is the example after making the above change. chaochn47/etcd-issues#2 (comment)

Does it sound good to you after the optimization from security perspective? @serathius @ahrtr

[chaochn47]

I guess the proposed approach is not a security best practice for etcd project since malicious users can abuse its usage.

Once ETCD as a kubernetes SIG is executed and we can reply on prow bot to fulfill the feature request like the issue title mentioned.

[jmhbnz]

Once ETCD as a kubernetes SIG is executed and we can reply on prow bot to fulfill the feature request like the issue title mentioned.

Agreed, and in the chance that doesn't go ahead we can consider running our own prow & bot instance. I'm working with CNCF on getting us some more on demand infra here #15953 via Equinix Metal initially just for our arm64 runners but we can expand in future if necessary.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[jmhbnz]

Closing - This is now working via /ok-to-test and other k8s ci robot commands following the merging of #16965 and prs in k8s/test-infra.

Now etcd members and reviewers can trigger and re-trigger tests using slash commands without having to wait for a maintainer, or force push from contributor.

There is further work to be done about considering more of a shift from github actions to prow jobs but that will be tracked separately, initial discussion is happening under: kubernetes/k8s.io#6102