4
votes

I created a new Rust project and decided, I'll give Github Actions a try to run automated builds and tests on each pull request:

name: Rust
on: [pull_request]

It took me a while to notice that by default, Github Actions does not checkout my code at all and the GITHUB_WORKSPACE is just empty. So, I tried manually cloning the repository. Doing something like this:

REPO=/tmp/path/to/repository
git clone https://github.com/myself/mycode.git $REPO

But this just checks out whatever is on the default branch. So, I investigated checking out $GITHUB_SHA which turns out to be something that is unknown to my repository. And the same is true for $GITHUB_REF which is just empty.

At this point I am clueless, about what I am doing. My initial assumption was that a job that is literally configured to run on: [pull request] should have exactly that code but it does not manage to checkout and prepare the it.

I also investigated the provided Checkout Actions:

This action checks out your repository to $GITHUB_WORKSPACE, so that your workflow can access the contents of your repository.

By default, this is equivalent to running git fetch and git checkout $GITHUB_SHA, so that you'll always have your repo contents at the version that triggered the workflow. See here to learn what $GITHUB_SHA is for different kinds of events.

But as I said before, the $GITHUB_WORKSPACE is entirely empty, and a git fetch will just tell you that there is no git repository.

Here's such an example failure:

On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
fatal: reference is not a tree: d76745134ae45905e4a0ab8d27c92f1e2544bdc1
##[error]Process completed with exit code 128.

What is the $GITHUB_SHA if it's unknown to my repository? Do I completely misunderstand Github Actions? How to checkout the latest commit with Github Actions, i.e., on a pull request?

Here's the chronology of my failures.

1
try adding - uses: actions/checkout@v1 as the first step in your steps. It's an official action provided by github and is the recommended way of setting up your project in CI/CD workflows. - Arne
Oh, I skimmed your post and didn't notice that you were aware of the action. Did you actually try it out? - Arne
Yes, check this job or that one, the checkout actions does not clone but download a tarball which is not available for every $GITHUB_SHA ... - Afr
You shouldn't put the github sha anywhere, the version for that action is just v1. Can you test the action with the exact string that I gave in my first comment? - Arne
That's actually part of the answer. It works. The $GITHUB_SHA is still incorrect but I am now at least where I want to be: HEAD detached at pull/15/merge - Afr

1 Answers

10
votes

You should use the official action that handles checkout. The github-actions' way of doing things takes some getting used to since it's a project management suite that doesn't solely cater to CI/CD needs.

So, some things are bound to be a bit strange or cumbersome, most of all because the documentation on all this isn't very mature yet - but hey, it's a beta for a reason.

The basic usage of this action is:

  • find the steps section where you would want to have your current commit checked out
  • add the action before writing a step that relies on the code to be there, usually at the very top
  • decide which version of the action you want to use, the tutorials will often have @master, but it's a little safer to name the current latest version - in this case @v1
  • enjoy your working workflow
jobs:
  build:
    runs-on: ubuntu-latest
    steps:

      # may or may not have a name, it's quite self-descriptive
      - uses: actions/checkout@v1

      # run steps that rely on the code in the commit that was pushed
      - name: test code
        steps: ...
      - name: build package
        steps: ...