Automatically ensure the machine gets push-access to a GitHub repository.

[a-t-0]

Either set up ssh-access, or generate a personal access token (Ideally for a particular repository) to allow:

• [ ] Push access.

• [ ] Repo creation access.

  A test to test this functionality could/should:

  • [ ] Assert the user does not have ssh-access.
  • [ ] Assert the user does not have a personal push access token available on the machine already.
  • [ ] Assert the personal push token is created correctly
  • [ ] The personal push token is allowed to create a repository.
  • [ ] The personal push token is allowed to push to the repository.

  Issue: If you do not want to create a personal access token that can delete GitHub repositories, you cannot repeatedly recreate the same repository anew (without deleting it manually).

Option A.:

A temporary solution could be to create a test-organisation and to allow it to fill up to 100 repos with name: testname0,testname1,...99 before throwing an error asking the user to manually delete the repos. (perhaps aided with a command to delete them all at once). Disadvantage:

1. Requires manual work. Advantage:
2. Does not allow machine to auto delete anything.

Option B.:

1. Create separate test-organisation.
2. Grant personal access token to that organization.

Disadvantage:

1. Pollutes GitHub account slightly.
2. Requires more manual work (also from other users).
3. If token is accidentally made in wrong organisation still allows for deletion

Advantage:

1. Assumption: personal access token can be specified to a specific organization. Status:unknown.
2. Does not allow machine to auto delete other/important repos (as long as token is made in the right organisation).

Option C.: Use specific deploy key to push to specific repository. Create that automatically instead. Assumption: can delete repo with deploy key. Status: unknown. Assumption: can create new repo with deploy key. Status: unknown.

Disadvantage:

1. None found.
2. May require user to create repo beforehand.
3. Still allows deletion of incorrect repo, if token is made accidentally at wrong repo.

Advantage:

1. No deletion of incorrect content.
2. Requires a single website automation.

Option D.: Automatically create personal access token to allow creating repo and pushing to repo. Then automatically create deploy key to delete that specific repository.

Advantage:

1. Is possible.

Disadvantage:

2. Requires two website automations instead of 1.

[a-t-0]

The following test from test_run_ci_on_github_repo.bats can be used to test if it works:

# TODO: write test that verifies this works on a new clean/empty repo.
# TODO: make this run after the loop over github branches.
@test "Test pushing GitHub commit build status to repo with build statusses is successful." {
    local github_username="a-t-0"
    local github_repo_name="sponsor_example"
    local github_branch_name="main"
    local github_commit_sha="85ad4b39fe9c9af893b4d7b35a76a595a8e680d5"

    copy_commit_build_status_to_github_status_repo "$github_username" "$github_repo_name" "$github_branch_name" "$github_commit_sha" "success"

    # TODO: write asserts
    # Assert svg file is created correctly
    assert_equal $(file_exists "$MIRROR_LOCATION/GitHub/$GITHUB_STATUS_WEBSITE_GLOBAL"/"$github_repo_name"/"$github_branch_name""/build_status.svg") "FOUND"

    # Assert GitHub commit build status txt file is created correctly
    assert_equal $(file_exists "$MIRROR_LOCATION/GitHub/$GITHUB_STATUS_WEBSITE_GLOBAL"/"$github_repo_name"/"$github_branch_name""/$github_commit_sha.txt") "FOUND"

    # Assert GitHub commit build status txt file contains the right data.
    assert_equal $(cat "$MIRROR_LOCATION/GitHub/$GITHUB_STATUS_WEBSITE_GLOBAL"/"$github_repo_name"/"$github_branch_name""/$github_commit_sha.txt") "success"

    push_commit_build_status_in_github_status_repo_to_github "$github_username"
    assert_success

    # Delete GitHub build status repository after test.
    sudo rm -r "$MIRROR_LOCATION/GitHub/$GITHUB_STATUS_WEBSITE_GLOBAL"
    assert_file_not_exist "$MIRROR_LOCATION/GitHub/$GITHUB_STATUS_WEBSITE_GLOBAL"
}

However, most likely a dedicated test would be better.

[a-t-0]

Since there is no need to create a new repository, there is also no need to delete any repository. This means a GitHub deploy key with push access to GitHub should be sufficient to complete the objective. This objective is to push the build status to the GitHub build status repo.

The tests to get the build statuses and to determine whether those build statuses are pushed correctly, already exist. So the thing that is being built and tested here is the automatic creation of a deploy key for a particular Github repository. That repository is in this case hard-coded in: src/hardcoded_variables.txt. It has the name:

GITHUB_STATUS_WEBSITE_GLOBAL=gitlab-ci-build-statuses

Solution:

• [x] Verify the GITHUB_STATUS_WEBSITE_GLOBAL=gitlab-ci-build-statuses repository exists.

  • [x] Do this at the start of the installation, in that case, ask the user to create the repository (open the website) and run the ./install_gitlab.sh -s -r again.
  • [ ] Assert the repository exists for this particular test again explicitly at the start.

• [x] Ensure no deploy key exists:

  • [x] Check if it exists, if it exists, delete it.

• [x] Assert no deploy key exists

• [x] Get the https://github.com/a-t-0/get-gitlab-runner-registration-token repository.

• [ ] Pass it an argument that lets it know it should not get the GitLab runner token, but create a GitHub deploy token instead.

• [ ] Let that code open the GItHub website at: github.com/$GLOBAL_GITHUB_USERNAME/$GITHUB_STATUS_WEBSITE_GLOBAL.

• [ ] Let it login

  • [ ] If the user is not logged in, ask user to login.
  • [ ] Loop every 10 seconds to see if user is logged in.
  • [ ] Once logged in, thank user and go to GITHUB_STATUS_WEBSITE_GLOBAL repository settings/
  • [ ] Verify the browser is in the correct repository.
  • [ ] Go to: create deploy key for that repository
  • [ ] Verify the browser is creating the deploy key for the correct repository.
  • [ ] Generate the ssh-key locally
  • [ ] Export the ssh-key towards a GitHub_deploy_key.txt outside the repository.
  • [ ] Give the deploy key a name.
  • [ ] Copy the deploy key into the browser.
  • [ ] Click submit

• [ ] Verify if the deploy key is able to push to the repository:

  • [ ] Clone the repository.
  • [ ] Check if the repo contains a test_boolean_false.txt
  • [ ] if it does, delete it, and create a test_boolean_true.txt
  • [ ] if it does not, create a test_boolean_false.txt
  • [ ] Verify the repo is changed.
  • [ ] Commit the changes.
  • [ ] Push the changes.
  • [ ] Verify the changes are pushed to the repository.

[a-t-0]

• [ ] Ensure generated key is deleted if one exists.
• [x] Generate an ssh-key.
• [x] Store that private key into `~/.ssh/GitHub_deploy_key.
• [x] Determine if public key is computed or stored somewhere as well.
• [x] Activate the ssh-agent in this shell.
• [x] Verify the agent is activated in this shell.
• [x] Add the ssh deploy key to that agent.
• [x] Verify the ssh deploy key is added to that agent.
• [x] Add the ssh deploy key to GitHub.
• [x] Verify shell has push access to the repo to which the deploy key was posted.