I have a single Github repository for both server and frontend. The directory structure looks like:
root
|- frontend
|- server (Express App)
Github Action:
name: Node.js CI
on:
push:
branches: [ main ]
jobs:
build:
runs-on: self-hosted
strategy:
matrix:
node-version: [14.x]
# See supported Node.js release schedule at https://nodejs.org/en/about/releases/
steps:
- uses: actions/checkout#v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node#v2
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- run: npm ci
working-directory: './server'
- run: npm run start
working-directory: './server'
I only have a single job to build the Express server (and not the frontend yet) so I set the working-directory to ./server. However, I still get an error:
Dependencies lock file is not found in /home/{username}/runners.../repository_name. Supported file patterns: package-lock.json,yarn.lock
So apparently it's not trying to run in .../reposirtoy_name/server.
I'm just trying to build both server and frontend in single Github action.
There might be a chance that your problem is specifically with "uses: actions/setup-node". They mention in the docs that if you have multiple lock files or a lock file(s) in a directory that is not the root
In my case I had a single project with nested projects/dir. In my GitHub actions I wanted to run npm test on the nested project/dir so I had to specify to use my package.json inside the specific sub-directory. Double check to see that you are specifying the right directories with cache-dependency-path.
Specified here
https://github.com/actions/setup-node#caching-packages-dependencies
Try out this solution. It worked in my case.
In the build insert the default working directory
build:
runs-on: self-hosted
defaults:
run:
working-directory: ./server/
strategy:
matrix:
node-version: [14.x]
Then include cache dependency path. This should be the location of your package-lock.json file
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
cache-dependency-path: './server/package-lock.json'
tldr
Make sure your checkout repo step is BEFORE setup node step, if using cache property with actions/setup-node#v3.
For me, it was caused by cache property on actions/setup-node#v3.
Without it - everything worked fine.
With it - failed. Reason is, it uses as cache key the package-lock.json (or yarn.lock) file.
See: https://github.com/actions/setup-node
My checkout repo step (actions/checkout#v2) was AFTER the setup node step, so it didn't find the package-lock.json file - because it wasn't checked out yet.
Related
I've been trying to get github actions to do the CI part of this particular test that has been created however, I also encounter a similar error when running the test. The test works locally, so that's great. When it's solely being ran with GitHub actions, it doesn't.
I first see a warning:
WARN #wdio/mocha-framework: Unable to load spec files quite likely because they rely on `browser` object that is not fully initialised.
which eventually becomes an error on the test:
ERROR #wdio/runner: Error: Unable to load spec files quite likely because they rely on `browser` object that is not fully initialised.
What else do I need to do in GitHub actions to get this to run the test and pass as it should?
The yml file has been set up to do the following:
name: CI
on: [push, pull_request]
env:
SAUCE_USERNAME: ${{ secrets.SAUCE_USERNAME }}
SAUCE_ACCESS_KEY: ${{ secrets.SAUCE_ACCESS_KEY }}
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout#v2
- name: Install Chromium
run: sudo apt-get install chromium-browser
- uses: actions/setup-node#v1
with:
node-version: 18
- name: Install
run: npm install
- name: Test
run: npx wdio wdio.git.js
- uses: actions/upload-artifact#v1
if: failure()
with:
name: logs
path: logs
You can also see the repo here: https://github.com/saucechaffe/sauceonsauceoff
I've attempted to change the yml file to configure different things, I've read that it isn't necessary to build chrome on the ubuntu machine but on some hands it is so I've left it in there for now. I've also attempted this: How to run WebdriverIO tests with GitHub Actions? but just keep getting stuck in the process.
Resolved this by removing a line of code that required chrome webdriver as it was causing the error and wasn't needed/being used.
I have the following action set up in my private GitHub repo:
# This workflow will do a clean install of node dependencies, build the source code and run tests across different versions of node
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions
name: Node.js CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [14.17.x]
steps:
- uses: actions/checkout#v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node#v1
with:
node-version: ${{ matrix.node-version }}
- run: yarn install --frozen-lockfile
- run: yarn test
Previously, the node-version was set to [15.x] and everything worked wonderfully. Since updating the required Node version to 14.17.x I have a check in my PRs that never resolves. It says:
build (15.x) Expected — Waiting for status to be reported Required
What am I missing here? It’s almost as if something is cached.
The issue ended up being a required status check that was added in “Settings » Branches » Require status checks to pass before merging » Require branches to be up to date before merging”. I removed that status check and re-added the updated version, then the message disappeared from the Checks list in all open PRs.
I have this workflow.yaml for github actions:
name: CI/CD
on:
push:
branches: [main]
pull_request:
branches: [main]
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [14]
steps:
- name: Checkout repository
uses: actions/checkout#v2
- name: Set up Node.js ${{ matrix.node-version }}
uses: actions/setup-node#v2
with:
node-version: ${{ matrix.node-version }}
- name: Install dependencies
uses: borales/actions-yarn#v2.0.0
with:
cmd: install --ignore-engines
- name: Run linters
uses: borales/actions-yarn#v2.0.0
with:
cmd: lint:prettier
- name: Run cypress
uses: cypress-io/github-action#v2
with:
build: npm run build
start: npm start
- name: Build
uses: borales/actions-yarn#v2.0.0
with:
cmd: build
Then it runs, on run cypress occurs an error:
error An unexpected error occurred: "EACCES: permission denied, unlink
'/home/runner/work/gos_front/gos_front/node_modules/.yarn-integrity'"
.
Before that I add cypress run all was right. I tried to add sudo but it not helped. I use yarn.
cypress-io/github-action tries to install dependencies as well and runs into an access issue. The problem is the way your node_modules folder is created.
I ran into this when using Docker, mapping node_modules from inside the docker image to the outside. This is a known issue.
You use borales/actions-yarn. This is an outdated package, that probably does something similar. You should instead use yarn directly. From their readme:
Please keep in mind that this Action was originally written for GitHub Actions beta (when Docker was the only way of doing things). Consider using actions/setup-node to work with Yarn. This repository will be mostly supporting the existing flows.
I am new to Gatsby and just tried a GH Actions workflow for my site today. I see this error at the build stage:
error "gatsby-source-github-api" threw an error while running the
sourceNodes lifecycle: token is undefined
I am using this to pull all repos on my Github into the site.
What I have tried so far:
Checked the Github personal access token
the build is working locally
Versions:
"gatsby-source-github-api": "^0.2.1" "gatsby": "^2.26.1"
This is my node.js.yml GH Actions workflow file:
name: Node.js CI
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [13.x]
# See supported Node.js release schedule at https://nodejs.org/en/about/releases/
steps:
- uses: actions/checkout#v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node#v1
with:
node-version: ${{ matrix.node-version }}
- run: npm ci
- run: npm run build
PS: I have used a .env file to hold the value of the token that the plugin 'gatsby-source-github-api' requires. And it is in my .gitignore file. So which means it is not sent to GH and hence can't find it?
So that was it -- the .env file which wasn't being pushed to Github.
So I needed to make the token available to the GH Action build somehow.
I tried the action SpicyPizza/create-envfile#v1. It isn't supported by Github but seemed to do the job. It creates a .env file at build with the keys you provide it.
You could also create a .env file manually. See thread.
I am using the GitHub cache action, but I noticed that the no cache will be created if the job fails. From the docs:
If the job completes successfully, the action creates a new cache with the contents of the path directory.
A stripped down version of my workflow YAML file:
name: Build
on: [push]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout#v1
- name: Setup Node.js
uses: actions/setup-node#master
with:
node-version: '10.x'
- name: Get yarn cache path
id: yarn-cache-dir-path
run: echo "::set-output name=dir::$(yarn cache dir)"
- name: Restore yarn cache
uses: actions/cache#v1
id: yarn-cache
with:
path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
restore-keys: |
${{ runner.os }}-yarn-
- name: Install yarn dependencies
run: yarn install
- name: Build
run: yarn build
I noticed that if my Build step fails the cache post-step will be skipped unnecessarily, which causes the installed dependencies to not be cached. This requires subsequent runs to download dependencies again, slowing down the job.
Is there a way to always cache the dependencies, even when the build step fails?
In the official version of the action, no it's not possible to cache dependencies if the build fails. See this line in the cache action's manifest:
runs:
using: 'node12'
main: 'dist/restore/index.js'
post: 'dist/save/index.js'
post-if: 'success()'
It will only run the post-step if the job succeeds. I don't know the original reasoning for this, but there are a few issues opened around this idea. In this issue a user forked the action to change the post-if to always(), which may be what you're after, assuming you're willing to run an unofficial action.