tsslade / w241_autograder

Notes

Accessing private repo

We are considering storing the testing suites in a private repo as a way of preventing users from simply accessing the code directly and thus evading any requirement to actually develop their own code.

Job 1 in implementing that approach is being able to access a (separate/different) private repo from a GitHub Action. The key elements of the GitHub Action required are as follows:

jobs:
  build:
   # ...other stuff here...
    steps:
      - name: Access contents of private repo  # You can call this whatever you want
        uses: actions/checkout@v2  # This refers to the GitHub Action. Nothing to do with your target repo
        with:
          repository: TSSlade/autograder_secrets  # This is your target repo. Uses `orgname/reponame` format
          token: ${{ secrets.w241_autograder }}  # This is your PAT (personal access token). Uses `secrets.your-PAT-name-here` format

The critical piece which is not self-evident or easily Google-able (but I found ❇ here ❇) is that you need to specifically add your PAT to the source repo of the GitHub Action. (This StackOverflow respondent apparently had a similarly mystifying experience.) 😡

Once you've created your PAT (and saved it elsewhere, please!!), you add it to your repo like so:

1. Go to your repo's Settings tab

   

2. Select the Secrets option in the left navbar

   

3. Select the New repository secret button in the top-right corner

   

4. Add in the name you're going to enter in that ${{ secrets.your-PAT-name-here }} line in the YAML file, then paste the token itself into the next field

Docs consulted along the way:

• GitHub Actions Docs: Creating a Personal Access Token 👍🏻
• GitHub Actions Docs: Authentication in a Workflow 👎🏻
• GitHub Actions Docs: Quickstart
• GitHub Actions issues: possible to checkout or clone another repo?
• GitHub Actions issues: retrieving the default branch name failed

Spinning up action

The key issue in getting this working is figuring out the proper location of the various component files and how to set the relative paths. This community post (Path to Action in the same repository as workflow) was the one that finally got everything clicking. The final arrangement looks something like this:

├── .github
│   ├── actions                     # Separating actions (components) from workflows makes sense
│   │   ├── Dockerfile              # Pulls the image from Dockerhub, copies in and executes the entrypoint.sh
│   │   ├── action.yml              # Defines inputs, outputs; -runs/image- has to resolve as a proper path
│   │   └── entrypoint.sh           # Does stuff. This is specific to our GitHub Action, not to Actions in general
│   └── workflows                   # This is where we store the YML files that link up the actions we store above
│       ├── ...elided...
│       └── main.yml                # This is the one we care about. --uses-- paths are either relative to GitHub public repos OR to your project root
├── README.md
...elided for parsimony...

The action.yml file has been cleaned up now, but see the below commits on the greetings branch for the errors generated by various permutations of the addresses/paths if you wish to reconstruct how we traced our way to this result.

2c69415 HEAD@{1}: commit: Updated paths, moved Dockerfile local to action.yml
9eee5ae HEAD@{2}: commit: Placed action in subfolder, updated paths
96cf275 HEAD@{3}: commit: Backing out the folder hierarchy
b50cdea HEAD@{4}: commit: Systematically testing addresses
51eee84 HEAD@{5}: commit: Consolidated yml files, updated address
b8c0755 HEAD@{6}: commit: Updated address of -uses-
da46f94 HEAD@{7}: commit: Updated repo name and Dockerfile pointer
c0b2e1c HEAD@{8}: commit: Updated to point to action file
b870579 HEAD@{9}: commit: Moved workflow to workflows
c731f1d HEAD@{10}: commit: Triggering a change...

There was also an issue with making sure the shebang on the entrypoint.sh hadn't been displaced out of the first-line position by my comments giving credit to original sources. (Don't trample over conventions, kids.) Realized and resolved that via this StackOverflow answer: standard_init_linux.go:211: exec user process caused “exec format error”

Executing Alex's script in the new Dockerfile

The default / MWE version used an ENTRYPOINT value of entrypoint.sh. After significant painful trial and error, I think I've settled on the following:

1. Verify you've made your ENTRYPOINT script executable (i.e., $ chmod +x the-file-name-here.sh)
2. You cannot execute that on the file until the file is within the Docker volume you're creating.
3. This means that your COPY src-file-here /target-file-here line in the Dockerfile needs to precede your $ chmod +x command.
4. It also appears that the src-file-here is living in a sort of no-man's land - your $ chmod +x can only act upon it once it has been moved into the scope of the volume (i.e., pay attention to the leading / in /target-file-here.)

Apropos of Nothing

Multiline strings in YAML syntax are 🍌 bananas 🍌: How do I break a string in YAML over multiple lines?