I have a simple workflow for my home app (front and back), all in one job, running on self-hosted runners:
- prepare environments for the builds (
apt install ...) - build the front to a directory
spa - copy the directory
spato the sources of the back - build the back (this will embed the
spadirectory in the binary) - deploy the binary to the home server
The reason for which these steps are linear is that I need the output from the front build for the back build.
This setup works.
name: build-n-deploy
on: push
jobs:
dash:
runs-on: self-hosted
steps:
- uses: actions/checkout@v2
with:
ref: master
- name: prepare build environment
run: |
apt update
apt install software-properties-common -y
add-apt-repository ppa:longsleep/golang-backports -y
curl -fsSL https://deb.nodesource.com/setup_14.x | sudo -E bash -
apt update && apt dist-upgrade -y
apt install nodejs -y
apt install golang-go -y
npm install -g @quasar/cli
- name: build front
working-directory: ./front
run: |
npm install
quasar build
cp -r dist/spa ../back
- name: compile back
working-directory: ./back
run: |
env GOOS=linux GOARCH=arm GOARM=5 go build -o dash.rpi
- name: deploy server files
(...)
For the sake of better understanding GitHub Actions and a more organized setup, I wanted to split this into several distinct jobs (rectangles with description below):
The environment preparation (that takes the most time) would run in parallel on two self-hosted runners.
I have one problem with this setup: I would obviously like to reuse the build environments for the actual build (the bolded red arrow in the flowchart above). How can I instruct a job to run in the environment of a previous job?
the other point is to transfer the directory spa generated during the build of the front to be the build of the back - for that I will use artifacts.
