Parallelism in CI/CD Pipelines like GitHub Actions - parallel-processing

Hello there and thank you for reading my question, its my first one here.
I am working with CI/CD pipelines for a year now and I think they are pretty nice and convinient for developing Websites and Stuff. But in the last months I have more and more problems creating fast, efficient and smart pipelines without redundant dependency installs or similar. So I want to use as less computation ressources as possible while still have fast builds. I want to parallelize steps and use theire artifacts in another final step. For example the following GitHub Actions workflow:
My goal with this workflow is to just build a VueJS Single Page App and deploy it to the IBM Cloud. For that I need to install the npm dependencies and build the Vue App and also install the IBM Cloud CLI. After these two steps are finished the builded App should be pushed to the IBM Cloud.
I could just simply run all steps sequentially like this:
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout#v2
- name: Use Node.js 10.X
uses: actions/setup-node#v1
with:
node-version: '10.x'
- name: Cache Node Modules
uses: actions/cache#v2
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
- name: Install Dependencies
run: npm ci
- name: Build Page
run: npm run build
- name: Install IBM Cloud CLI
run: curl -fsSL https://clis.cloud.ibm.com/install/linux | sh
shell: bash
- name: Install Cloud Foundry CLI
run: ibmcloud cf install
shell: bash
- name: Authenticate with IBM Cloud CLI
run: ibmcloud login --apikey "${{ secrets.IBM_CLOUD_API_KEY }}" --no-region -g Default
shell: bash
- name: Target a Cloud Foundry org and space
run: ibmcloud target --cf-api "${{ secrets.IBM_CLOUD_CF_API }}" -o "${{ secrets.IBM_CLOUD_CF_ORG }}" -s "${{ secrets.IBM_CLOUD_CF_SPACE }}"
shell: bash
- name: Deploy to Cloud Foundry
run: ibmcloud cf push
shell: bash
But in my opinion this is very ugly and can be improved. So I tried to split the job into 3 parts: build, predeploy and deploy. The build job installs and builds the Vue App. The Predeploy job install the IBM CLI. These two jobs doesn't depend on each other so they can be parallized. But the last job, deploy, depends on both so I added the needs: [build, predeploy] value to it. So I have the following workflow to archive this:
### This will not work!
name: Deploy
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout#v2
- name: Use Node.js 10.X
uses: actions/setup-node#v1
with:
node-version: '10.x'
- name: Cache Node Modules
uses: actions/cache#v2
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
- name: Install Dependencies
run: npm ci
- name: Build Page
run: npm run build
predeploy:
runs-on: ubuntu-latest
defaults:
run:
shell: bash
steps:
- name: Install IBM Cloud CLI
run: curl -fsSL https://clis.cloud.ibm.com/install/linux | sh
- name: Install Cloud Foundry CLI
run: ibmcloud cf install
- name: Authenticate with IBM Cloud CLI
run: ibmcloud login --apikey "${{ secrets.IBM_CLOUD_API_KEY }}" --no-region -g Default
- name: Target a Cloud Foundry org and space
run: ibmcloud target --cf-api "${{ secrets.IBM_CLOUD_CF_API }}" -o "${{ secrets.IBM_CLOUD_CF_ORG }}" -s "${{ secrets.IBM_CLOUD_CF_SPACE }}"
deploy:
needs: [build, predeploy]
runs-on: ubuntu-latest
steps:
- name: Deploy to Cloud Foundry
# Error: 'ibmcloud: command not found'
run: ibmcloud cf push
shell: bash
Which looks on the GUI like:
[![My GitHub Workflow on the GUI][1]][1]
But this workflow will error since the last job doesn't share the same environment as the other jobs. I am aware that I could use the up/download Artifact feature of GitHub Actions but this seems to me like using a lot of resources. But I dont want to use a lot of ressources for my pipeline, I dont need a lot of different virtual environments or build matrixes. (I know they are very good for large projects, but they seem a little overkill for my little site)
So here are my two final Questions:
Why is parallelism in CI/CD often complication and not straight forward?
How can I improve my current pipeline with parallelism and without redundant executions?
I am glad about every helpful advice or link. Thank you. :)
[1]: https://i.stack.imgur.com/qEqLs.png

I think your original workflow was already pretty efficient. As you mentioned, different jobs are executed on different runners and sometime the additional complexity and effort put into the synchronization/logic between workflows outweighs the benefits of parallelism. In your case I don't think it would make much sense to run your jobs in parallel.
For your first question, I don't think it's an issue specific to CI/CD pipelines. I am getting a bit out of scope here but you have similar issues in any code that does work in parallel or as a matter of fact in any work in general that is done in parallel anywhere. Being factories, teams, code, CI pipelines, as soon as the work is split up, there will be some sort of mechanism to manage the allocation of work and track its progress. Which will make it more complex.
Why GH workflows might seem less straightforward than other systems seem to be a better question and I think it comes does to how long it has been around. It's a pretty recent addition to github and as new features are progressively being added it gets easier and easier to work with.
Regarding other optimizations for your workflow, I would recommend trying to avoid redoing the same work every time the workflow run if it's not needed. You already do this with the cache action for npm. But you could, for example build a docker image, or even better an action ,with your IBM CLI in it and remove the pre-deploy stage entirely. Simply having:
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout#v2
- name: Use Node.js 10.X
uses: actions/setup-node#v1
with:
node-version: '10.x'
- name: Cache Node Modules
uses: actions/cache#v2
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
- name: Install Dependencies
run: npm ci
- name: Build Page
run: npm run build
- name: Deploy to Cloud Foundry
uses: my-action:v1
with:
api-key: ${{ secrets.IBM_CLOUD_API_KEY }}
cf-api: ${{ secrets.IBM_CLOUD_CF_API }}
cf-org: ${{ secrets.IBM_CLOUD_CF_ORG }}
cf-space: ${{ secrets.IBM_CLOUD_CF_SPACE }}

Related

How to set up a monorepo in SonarCloud with a Java + Angular application

I have developed an application where the backend is developed using Java language (with maven) and the frontend is using Angular language. I host both parts in one project in github.
Now I am interested on the use of SonarQube on SonarCloud. For this purpose, I am following the information gathered from the community sonarsource and the standard documentation from sonarcloud. The idea is to use GiHub Actions for analyzing the projects.
What I have created is a .github/workflows/build.yml on the root folder with the content:
name: Build
on:
push:
branches:
- master
pull_request:
types: [opened, synchronize, reopened]
jobs:
sonarcloud:
name: SonarCloud
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
with:
fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis
- name: Set up JDK 11
uses: actions/setup-java#v1
with:
java-version: 11
- name: Cache SonarCloud packages
uses: actions/cache#v1
with:
path: ~/.sonar/cache
key: ${{ runner.os }}-sonar
restore-keys: ${{ runner.os }}-sonar
- name: Cache Maven packages
uses: actions/cache#v1
with:
path: ~/.m2
key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
restore-keys: ${{ runner.os }}-m2
- name: Build and analyze
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Needed to get PR information, if any
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
run: mvn -B verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.projectKey=kendo-tournament-backend
with:
projectBaseDir: ./backend/
- name: SonarCloud Frontend Scan
uses: SonarSource/sonarcloud-github-action#master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Needed to get PR information, if any
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
with:
projectBaseDir: ./frontend/
Where basically, I create some steps for executing the maven project, and another extra step to execute the frontend. On both of them, I included the projectBaseDir with the path to both projects' folders as specified here.
Also, as suggested on the documentation, I have included a sonar-project.properties on the root folder of the frontend folder with:
sonar.projectKey=kendo-tournament-frontend
sonar.organization=softwaremagico
# This is the name and version displayed in the SonarCloud UI.
#sonar.projectName=Kendo Tournament Manager Frontend
#sonar.projectVersion=1.0
# Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows.
#sonar.sources=.
# Encoding of the source code. Default is default system encoding
#sonar.sourceEncoding=UTF-8
And for the backend, I have updated the root pom.xml with the:
<properties>
<sonar.organization>softwaremagico</sonar.organization>
<sonar.host.url>https://sonarcloud.io</sonar.host.url>
</properties>
As required.
But, no analyses scan is launch for any of both projects. And SonarCloud looks like is ignoring the configuration.
Probably, something is missing but I cannot imagine what. What steps are needed to set up a monorepository correctly using Java and Angular in Github?
Ok, after the example obtained from here. The changes I have made are:
Two different workflows on github, one for backend and one for frontend. Not one workflow with all steps together.
Include two different sonar-project.properties. One inside the backend folder, and one inside the frontend folder. Now I have added the sonar.sources line as follows:
sonar.projectKey=kendo-tournament-backend
sonar.organization=softwaremagico
sonar.sources=.
That ensures that is only for this folder.
For launching CircleCi with Sonar (for backend) edit file .circleci/config.yml:
version: 2.1
jobs:
build:
docker:
- image: 'circleci/openjdk:11-jdk'
working_directory: ~/KendoTournamentManager/backend
steps:
- checkout:
path: ~/KendoTournamentManager
- run:
name: Analyze on SonarCloud
command: mvn verify sonar:sonar -Dsonar.projectKey=kendo-tournament-backend
workflows:
main:
jobs:
- build:
context: SonarCloud
And now seems working fine:

Is that possible to deploy Laravel web application to shared hosting using GitHub Action & GitHub FTP Deploy?

Is that possible to deploy the Laravel web application to shared hosting using GitHub Action & GitHub FTP Deploy? If possible how should I change the.github\workflows\master.yml?
on:
push:
branches:
- master
name: 🚀 Deploy website on push
jobs:
web-deploy:
name: 🎉 Deploy
runs-on: ubuntu-latest
steps:
- name: 🚚 Get latest code
uses: actions/checkout#v2
- name: 📂 Sync files
uses: SamKirkland/FTP-Deploy-Action#4.2.0
with:
server: ${{ secrets.ftp_server }}
username: ${{ secrets.ftp_username }}
password: ${{ secrets.ftp_password }}
server-dir: /
Looks like you're very close but are missing 2 important steps: set up a temporary PHP environment, and use that environment to install your dependencies (Composer).
GitHub Actions Setup
This guide assumes you have a working Laravel installation, a GitHub account, and a shared hosting account that you can access via FTP using a username/password.
I found this video https://www.youtube.com/watch?v=UNWIXYSZfZY helpful to get a basic understanding of how to deploy a simple application. To make this answer helpful to a wider range of people, I'll give a quick outline of my setup. There really aren't any Laravel specific steps.
Workflow directory set up
Create the directories .github\workflows at the root of your project. In the workflows directory, create a yml file named after the branch you want to push to your shared hosting account. Ex. master.yml, staging.yml, development.yml etc. If you only have a single branch then just create one file. The name is important and should match the name of the branch.
Design your workflow
This is very dependent on your project but assuming you have a basic Laravel application without the need for additional components such as Node, then this is a basic GitHub Action that works for me on a variety of projects.
A basic action file consists of 2 sections, the workflow, and the jobs. A workflow triggers the jobs.
Workflow
Lines 1-4 say this will run each time we push to the master branch.
on:
push:
branches:
- master
Line 5 is the name of this workflow and will show up on your Actions page. Set this to something descriptive.
name: 🚀 Deploy website on push (Master)
Setting up jobs
In this action, there are 5 jobs. Some take parameters, others don't. I'm not going to explain all the details here but have linked to the corresponding repositories if you need details.
Checkout your code so the workflow has access to it,
https://github.com/actions/checkout
name: 🚚 Get latest code
uses: actions/checkout#v2
Sets up a temporary PHP environment so you can run things like
Composer, https://github.com/shivammathur/setup-php. Make sure to set your PHP version here otherwise you could run into issues when installing Composer packages with an unexpected PHP version.
name: Setup PHP
uses: shivammathur/setup-php#v2
with:
php-version: 7.2
Caches your dependencies for faster deploys,
https://github.com/actions/cache
name: Cache Composer packages
id: composer-cache
uses: actions/cache#v2
with:
path: vendor
key: ${{ runner.os }}-php-${{ hashFiles('**/composer.lock') }}
restore-keys: |
${{ runner.os }}-php-
Install your dependencies from composer.json and composer.lock
files.
name: Install dependencies
run: composer install --prefer-dist --no-progress
Deploys your code to your remote shared hosting site,
https://github.com/SamKirkland/FTP-Deploy-Action. Note the use of ${{ secrets.ftp_username }} and ${{ secrets.ftp_password }}. These are set up in your repository's secrets section. See https://docs.github.com/en/actions/security-guides/encrypted-secrets
name: 📂 Sync files
uses: SamKirkland/FTP-Deploy-Action#4.0.0
with:
server: name_of_server.com
username: ${{ secrets.ftp_username }}
password: ${{ secrets.ftp_password }}
server-dir: public_html/
Final file
on:
push:
branches:
- master
name: 🚀 Deploy website on push (Master)
jobs:
web-deploy:
name: 🎉 Deploy
runs-on: ubuntu-latest
steps:
- name: 🚚 Get latest code
uses: actions/checkout#v2
- name: Setup PHP
uses: shivammathur/setup-php#v2
with:
php-version: 7.2
- name: Cache Composer packages
id: composer-cache
uses: actions/cache#v2
with:
path: vendor
key: ${{ runner.os }}-php-${{ hashFiles('**/composer.lock') }}
restore-keys: |
${{ runner.os }}-php-
- name: Install dependencies
run: composer install --prefer-dist --no-progress
- name: 📂 Sync files
uses: SamKirkland/FTP-Deploy-Action#4.0.0
with:
server: name_of_server.com
username: ${{ secrets.ftp_username }}
password: ${{ secrets.ftp_password }}
server-dir: public_html/
Running the workflow
Check-in .github\workflows\master.yml, and others if appropriate,
into your GitHub repository. Without these files checked in nothing
will happen when you push a change to the branch.
Go to your Actions tab and ensure the workflow shows up there.
Push a change to your branch and watch the Actions tab. Click into
the running action to see details about the run.
Fix any errors that show up in the console.
Finally, you mentioned in a comment something about NPM. If you have Node as a component in your project you can simply run two extra steps that will bundle your assets and will get deployed along with the rest of the code.
Good luck!

Issues creating a CD based release on Github (WPF .NET 5.0)

I'm trying to put together a CI / CD pipeline for GitHub and strugglign with attaching my build artifact to the release. Here's my ci.yml
name: CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
workflow_dispatch:
jobs:
Build:
runs-on: windows-latest
env:
BuildPath: ${{ github.workspace }}\BuildTesting\bin\Release\net5.0-windows
steps:
- uses: actions/checkout#v2
- name: Setup .NET SDK
uses: actions/setup-dotnet#v1.8.1
with:
dotnet-version: 5.0.x
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Upload a Build Artifact
uses: actions/upload-artifact#v2.2.4
with:
name: thingy
path: ${{ github.workspace }}\BuildTesting\bin\Release\net5.0-windows
retention-days: 1
That runs well and I get a release artifact:
I was under the impression I'd be able to download that existing artifact but I couldn't get my head around why actions/download-artifact isn't downloading anything. So I found another article and in their cd step they were re-building, so I figured that in doing that at least I'd have a fresh build in the cd workflow to pull from. So I create a release triggered on tag push events. I can't use most zip utilities becuase they don't run on windows. I have to user windows-latest as the target framework for WPF desktop applications has to be net5.0-windows and using ubuntu-latest it fails. I tried papeloto/action-zip#v1 and in one case I managed to get a zip file which then attached to the release successfully but was only 22 bytes, so empty once I downloaded it. Here's my cd.yml:
name: CD
on:
push:
tags:
- '*'
jobs:
Release:
runs-on: windows-latest
env:
BuildPath: ${{ github.workspace }}\BuildTesting\bin\Release\net5.0-windows
ZipName: TheThing.zip
steps:
# Build the solution
- uses: actions/checkout#v2
- name: Setup .NET SDK
uses: actions/setup-dotnet#v1.8.1
with:
dotnet-version: 5.0.x
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Zip the release
uses: << What should I use to zip ${{ env.BuildPath }} ? >>
# Create a Release on the GitHub project
- name: Create release
id: create_release
uses: actions/create-release#v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
with:
tag_name: ${{ github.ref }}
release_name: ${{ github.ref }}
draft: false
prerelease: false
# Upload the Build Artifact to the Release
- name: Update release asset
id: upload-release-asset
uses: actions/upload-release-asset#v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
upload_url: ${{ steps.create_release.outputs.upload_url }} # This pulls from the CREATE RELEASE step above, referencing it's ID to get its outputs object, which include a `upload_url`. See this blog post for more info: https://jasonet.co/posts/new-features-of-github-actions/#passing-data-to-future-steps
asset_path: .\${{ env.ZipName }}
asset_name: ${{ env.ZipName }}
asset_content_type: application/zip
Can anyone please recommend a GitHub action for zipping a folder that will work for windows-latest ... or another approach?
Long term I want to go with semantic versioning but GitVersion overwhelmed me last time I tried, granted I'd never working with yml builds before. I'd like to keep this as simple as possible as I'm starting to grok the basics of what's going on and once I get past this I'll start looking into GitVersion.
I'm using a test repository located here so you can see the whole thing.
You may use PowerShell to zip your artifacts using 7Zip. Please check my repository in GitHub. That compile a WPF app, compress the artifacts, create a prerelease and upload files under that release.

Github Action Cache question with containers

I got a quick question and I can't find docs on it (maybe it is impossible)
How can I retrieve what has been built from a container (like this) :
prod-dependencies:
name: Production Dependencies
runs-on: ubuntu-20.04
container: elixir:1.11-alpine
env:
MIX_ENV: prod
steps:
- name: Checkout
uses: actions/checkout#v2
with:
fetch-depth: 0
- name: Retrieve Cached Dependencies
uses: actions/cache#v2
id: mix-prod-cache
with:
path: |
${{ github.workspace }}/deps
${{ github.workspace }}/_build
key: PROD-${{ hashFiles('mix.lock') }}
- name: Install Dependencies
if: steps.mix-prod-cache.outputs.cache-hit != 'true'
run: |
apk add build-base rust cargo
mix do local.hex --force, local.rebar --force, deps.get --only prod, deps.compile
I need to build on Alpine since I am deploying on Alpine and some C libs are different for the Erlang VM to work.
So here it is the place where I build dependencies and I want to put them on cache for the subsequent jobs but the cache is never populated. According to doc GitHub mount a volume with containers to retrieve artifacts but I must miss use it.
Thanks a lot for your help.
Here is a sample Github workflow for an Elixir app with a Postgres database that utilizes the action/cache#v2. Note that it defines 2 separate steps for restoring the deps and _build directories. In this workflow, the mix deps.get and mix compile steps are always run: they should execute very quickly if the cache is restored.
Adapted from this workflow
name: Test
on:
pull_request:
branches:
- develop
paths-ignore:
- 'docs/**'
- '*.md'
jobs:
test:
name: Lint and test
runs-on: ubuntu-18.04
env:
MIX_ENV: test
services:
db:
image: postgres:11
ports: ['5432:5432']
env:
POSTGRES_PASSWORD: postgres
options: >-
--health-cmd pg_isready
--health-interval 10s
--health-timeout 5s
--health-retries 5
steps:
- uses: actions/checkout#v2
- uses: erlef/setup-elixir#v1
with:
otp-version: '23.1.2'
elixir-version: '1.11.2'
- name: Configure SSH for private Repos
uses: webfactory/ssh-agent#v0.4.1
with:
ssh-private-key: ${{ secrets.HEADLESS_PRIV }}
- name: Restore the deps cache
uses: actions/cache#v2
id: deps-cache-restore
with:
path: deps
key: ${{ runner.os }}-deps-mixlockhash-${{ hashFiles(format('{0}{1}', github.workspace, '/mix.lock')) }}
restore-keys: |
${{ runner.os }}-deps-
- name: Restore the _build cache
uses: actions/cache#v2
id: build-cache-restore
with:
path: _build
key: ${{ runner.os }}-build-mixlockhash-${{ hashFiles(format('{0}{1}', github.workspace, '/mix.lock')) }}
restore-keys: |
${{ runner.os }}-build-
- name: Get/update Mix dependencies
run: |
mix local.hex --force
mix local.rebar
mix deps.get
- name: Compile
run: mix compile
- name: Create database
run: mix ecto.create
- name: Migrate database
run: mix ecto.migrate
- name: Test
run: mix test

Migrating to GitHub Actions from Travis keeps failing

I am currently completing a migration from travis CI to Github Actions CI however my build keeps failing when the container tries to connect to my test DB.
Its a very generic error
UNKNOWN_CODE_PLEASE_REPORT: An internal error has occurred. Please retry or report your issues.
at Handshake.Object.<anonymous>.Sequence._packetToError (node_modules/***/lib/protocol/sequences/Sequence.js:47:14)
at Handshake.Object.<anonymous>.Handshake.ErrorPacket (node_modules/***/lib/protocol/sequences/Handshake.js:123:18)
at Protocol.Object.<anonymous>.Protocol._parsePacket (node_modules/***/lib/protocol/Protocol.js:291:23)
at Parser._parsePacket (node_modules/***/lib/protocol/Parser.js:433:10)
at Parser.write (node_modules/***/lib/protocol/Parser.js:43:10)
at Protocol.Object.<anonymous>.Protocol.write (node_modules/***/lib/protocol/Protocol.js:38:16)
at Socket.<anonymous> (node_modules/***/lib/Connection.js:88:28)
at Socket.<anonymous> (node_modules/***/lib/Connection.js:526:10)
Additional Notes: My test DB is hosted on Azure (mysql server) and my tests execute fine on local and previously on travis. Project details: NodeJs project running TypeOrm for MySql.
This is what the current base version of my yml looks like:
on:
pull_request:
branches: [master, develop]
defaults:
run:
working-directory: ./Server
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Use Node.js
with:
node_version: 14.x
uses: actions/setup-node#v1
- name: Run tests
run: |
npm install
npx jest --coverage --config ./jest.config.js
env:
TEST_DB_NAME: ${{ secrets.TEST_DB_NAME }}
TEST_DB_PORT: ${{ secrets.TEST_DB_PORT }}
TEST_DB_TYPE: ${{ secrets.TEST_DB_TYPE }}
TEST_HOST: ${{ secrets.TEST_HOST }}
TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }}
TEST_PORT: ${{ secrets.TEST_PORT }}
ACCESS_SECRET_KEY: ${{ secrets.ACCESS_SECRET_KEY }} ```
Answering my own question:
I was missing an extra env key/variable related to an external AP. This was causing the failure.

Resources