Fixes and improvements to github role

[jackhodgkiss]

No description provided.

[markgoddard]

This could really use a basic test that at least runs the role.

[markgoddard]

Why does it need write permission?

[Alex-Welsh]

Do we need to check the branch protection on this repo? seems like it's a bit open at the moment

[jackhodgkiss]

Do we need to check the branch protection on this repo? seems like it's a bit open at the moment

Resolved.

[markgoddard]

Is this for creating PRs?

[jackhodgkiss]

It is for pushing any changes back to the repository. Any PRs are opened manually.

[markgoddard]

Manually? What about the stuff in kayobe-automation for opening PRs?

[jackhodgkiss]

I will investigate and update shortly. However, from my experience if any changes get staged it will print a link that when you click on fills out all the PR information and then you open the PR.

[markgoddard]

Looks like it should create a PR:

function github_pull_request {
    local branch_name="$(pull_request_branch_name)"

    _git_commit "${branch_name}"

    local body="{
        \"head\": \"${branch_name}\",
        \"base\": \"${KAYOBE_AUTOMATION_PR_TARGET_BRANCH}\",
        \"title\": \"${KAYOBE_AUTOMATION_PR_TITLE}\"
    }"

    log_debug "Pull request body: $body"

    # Support 0Auth token? Current method requires a personal access token, but
    # we might have access to 0Auth token in the gitlab runner? Recommended to
    # to setup a service account otherwise.
    # --header "Authorization: token ${KAYOBE_AUTOMATION_PR_AUTH_TOKEN}" \

    log_info "Submitting merge request to: $KAYOBE_AUTOMATION_PR_URL"

    # https://docs.github.com/en/rest/reference/pulls
    curl -X POST "$KAYOBE_AUTOMATION_PR_URL" \
        --user "${KAYOBE_AUTOMATION_PR_GITHUB_USER}:${KAYOBE_AUTOMATION_PR_AUTH_TOKEN}" \
        --header "Accept: application/vnd.github.v3+json" \
        --header "Content-Type: application/json" \
        --data "${body}" | jq "."

    log_info "Pull request created sucessfully"
}

[jackhodgkiss]

After a quick test I have realised what has been occuring. On the rare occassion where a service deploy or similar has changes to cmmit it will attempt to open a PR after pushing the changes to a new branch.

It will not fail if it cannot either due to lack of permissions on the token or repository wide settings preventing Actions from openning a PR.

Without

permissions:
  pull-requests: write

You will silently get the following error.

Resource not accessible by integration

Once applied you must also enable support for Actions to open PRs within the repository settings under Settings -> Actions -> General -> Workflow Permissions. Otherwise you silently get the following error.

{
  "message": "GitHub Actions is not permitted to create or approve pull requests.",
  "documentation_url": "https://docs.github.com/rest/pulls/pulls#create-a-pull-request"
}

Whether set appropriately or not the workflow should be capable of pushing to the repository which in the logs will contain a link to open a PR.

Will update template to include support for this. Thanks.

[markgoddard]

Thanks for the detailed write up. GitHub API does claim to provide a success/fail response: https://docs.github.com/en/free-pro-team@latest/rest/pulls/pulls?apiVersion=2022-11-28#create-a-pull-request--status-codes

But it appears we are not failing in kayobe-automation when we get a 403. I've proposed a PR to address this here.

[markgoddard]

I think just to tie this off, we should only assign write permission when:

'KAYOBE_AUTOMATION_PR_TYPE' in workflow.arguments

[markgoddard]

New condition looks good, but need a similar one for content

[markgoddard]

Nice work, looking good!