16

I woke up to my GitHub Actions BETA invite this morning (wooo) and have started playing with it, with the aim of migrating some simple build, test and deploy pipelines I currently have running on CircleCI.

I'm still trying to get my head around Actions, but the flow I have in mind is that after a push, the first Action in the workflow will launch a Docker container. Inside that container I'll run some simple build processes such as minimising assets and removing artefacts. The next Action will then run some tests on the build. And the next Action(s) in the pipeline will deploy to one of a number of environments, depending on the branch I pushed to.

I've followed the docs at https://developer.github.com/actions/creating-github-actions/creating-a-docker-container/ and have a rudimentary workflow that launches a Docker container and runs some build commands inside the WORKDIR. I'm also able to run a deployment (via rsync) from inside this WORKDIR too.

However, I'd like to split this into separate steps/Actions, but I can't figure out a way to to this.

Essentially, this would be similar to the CircleCI jobs/workflow model I'm using. However, with CircleCI, the first job runs a build then persists the resulting directory structure throughout the rest of the workflow, like this:

# Persist dist directory
  - persist_to_workspace:
      root: ~/project
      paths:
        - .

So, I'm kinda equating CircleCI's Jobs to GitHub's Actions here, which is possibly the wrong thing to do? Essentially, what I'm trying to find out is whether I can persist a WORKDIR inside the first Action's Docker container and make that WORKDIR available to subsequent Actions.

Is this possible, or am I way off with what I'm imagining GitHub Actions can do?

Thanks!

Bless
  • 5,052
  • 2
  • 40
  • 44
Contention
  • 539
  • 5
  • 19
  • wonderful question! I really miss that `persist_to_workspace` from circleci and also split by timings that github actions does not. anyone suggesting to do it via upload/download is not entirely wrong, but not correct either. When you go serious enterprise and have testcontainers with many docker images, this approach is just not an option at all. – Eugene Jul 30 '22 at 13:20

3 Answers3

10

Answering this myself in case someone else runs into this issue (and, like me, didn't fully read the docs!). :o)

The docs here explain, but essentially the working directory of any container you start as part of an action exists as /github/workspace. Actions can modify the contents of this working directory, and when containers are started in subsequent actions during the workflow, the working directory for these actions/containers will contain the modifications made earlier in the workflow.

So, the answer is yes, the Docker WORKDIR at /github/workspace is persisted throughout a GitHub Actions workflow in a similar way to how it can persist in a CircleCI workflow.

Contention
  • 539
  • 5
  • 19
  • 5
    It would be nice if you could persist workspaces between jobs while using `job.needs` to run jobs in parallel for faster feedback (not having to run expensive `yarn install` or `yarn build` steps multiple times, e.g.). – JaKXz Nov 06 '19 at 20:30
  • I think this functionality has changed. I was eager to try this, but unfortunately I think jobs are no longer persistent at all. – Greg Nov 25 '19 at 12:05
  • I'm in the same boat as @JaKXz. It would be nice if I could have 1 job to do a `checkout && npm install`, and use `needs` for other jobs to lint, check types, and eventually build the project. Is this still not possible? – s.meijer Feb 27 '20 at 13:15
  • 1
    The page [here](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners) says "Each job in a workflow executes in a fresh instance of the virtual machine", so I don't think you can persist data among multiple VMs this way. – Hritik Mar 27 '21 at 21:06
  • 2
    Here is a working solution https://stackoverflow.com/a/57877438/2251364 – Hritik Mar 27 '21 at 21:51
4

On my tests today, it cannot persist files between jobs. CircleCi does, there you can store some content to read on next jobs, but on GitHub Actions I can't.

Following, my tests:

Write file on a job, try to read on the next

Used test file.

1) Writing on GITHUB_WORKSPACE
My path: /home/runner/work/github-actions-test/github-actions-test)
Results: writeable and readble on first job, but, empty on second job Action link

2) Writing on /github/home
My path: /github/home
Results: cannot access '/github/home/ Action link

3) Writing on /home
My path: /home
Results: touch: cannot touch '/home/myFile.txt': Permission denied
Action link

Tiago Gouvêa
  • 15,036
  • 4
  • 75
  • 81
0

I think actions/upload-artifact@v3 is the latest solution.

  - name: Create a file
    run: echo "I won't live long" > my_file.txt

  - name: Upload Artifact
    uses: actions/upload-artifact@v3
    with:
      name: my-artifact
      path: my_file.txt
      retention-days: 5

Real world example mdn/content repo:

  1. Build and upload happens in pr-test.yml
  2. The build is downloaded and deployed in pr-review-companion.yml
the Hutt
  • 16,980
  • 2
  • 14
  • 44