We are actually moving our repos to github and we want to use github actions for our pipelines, also our testautomation framework based on WebdriverIO. I'm completely new to github actions, I'm more an expert for Jenkins and Jenkins pipelines.
So, there is a really small github actions example on WebdriverIO webpage, but it is not really helpful for us/me. I try to execute only some tests on pushing some stuff to a branch. We are running that currently on "ubuntu-latest" image and I try to execute only some simple web tests, but it is not really easy possible. I tried the following ways at first:
Executing the tests using the chromedriver directly on ubuntu-latest image occurs an error:
ERROR webdriver: Request failed with status 500 due to unknown error: unknown error: Chrome failed to start: exited abnormally.
Using the wdio docker service with docker image "selenium/standalone-chrome-debug" produces also an error. If I re-run this job, then everything is fine. It is also a problem with a first run, bit the first run is the more interesting one ;):
ERROR wdio-docker-service: Failed to run container: request to http://localhost:4444/ failed, reason: connect ECONNREFUSED 127.0.0.1:4444
Maybe you have some experiences, recommendations or examples for me to solve that issue? What is the best way to execute WebdriverIO tests via GitHub actions?
This is my github action workflow yaml:
name: Testautomation Example
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout#v2
- name: Setup
run: npm install
- name: Test
# 1. issue with chromedriver
#run: ENV_PATH=environment/QS npm run clear-test -- "wdio-configs/wdio.conf.chrome.chromedriver.js --cucumberOpts.tagExpression=#example"
# 2. issue with wdio docker service
run: ENV_PATH=environment/QS npm run clear-test -- "wdio-configs/wdio.conf.chrome.docker.debug.js --cucumberOpts.tagExpression=#example"
- name: Upload Test Reports
uses: actions/upload-artifact#v2
with:
name: reports
path: tests/reports/
- name: Upload Logs
uses: actions/upload-artifact#v2
with:
name: logs
path: log/
I've solved my issues and this is an example github workflow for the github actions:
name: Multiple Environments Example
on: [push, pull_request]
jobs:
e2e-test-on-ubuntu-with-local-chrome:
runs-on: ubuntu-latest
#runs-on: macos-latest
#runs-on: windows-latest
steps:
- name: Checkout
uses: actions/checkout#v2
- name: Setup
run: npm install
- name: Test
run: npm run clear-test -- "wdio-configs/wdio.conf.chrome.chromedriver.headless.js --cucumberOpts.tagExpression=#myTests"
env:
ENV_PATH: environment/QS
- name: Upload Test Reports
uses: actions/upload-artifact#v2
with:
name: reports
path: tests/reports/
- name: Upload Logs
uses: actions/upload-artifact#v2
with:
name: logs
path: log/
Related
I am trying to find a way to run unit tests automatically on a project hosted by amplify using Github Actions to trigger the unit tests on pull request.
On each instance of the action, it is failing on line
import awsconfig from 'aws-exports';
With the error:
Cannot find module 'aws-exports' from 'src/resource/utils/HttpMethods.js'
The issue seems to be that the aws-exports file is generated by Amplify at build time, however, since these test are being run on github when a PR is created, Amplify has not yet built out and has not generated the aws-exports file.
I'm sure I'm not the first person to want to run automated unit tests for an Amplify hosted site. Has anyone encountered this issue/found a solution?
My github action for reference:
name: Node CI
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [16.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
- run: yarn test
I have already tried removing the aws-exports from the gitignore and manually posting it to the repo. This worked but is not ideal since amplify will re-generate this file on build.
edit
My current (working?) solution is to create a dummy config file for each environment, which contains the contents that the aws-exports would contain if it had built. I import this file instead of aws-exports.
While this solution "works" for now, it feels flimsy, and I would much rather have a proper solution.
I was able to use the amplify-cli-action to configure amplify in my GitHub Actions.
Note: I had to make a minor update to the default example to include amplify_cli_version: 10.6.1 as described in a workaround to this issue: https://github.com/ambientlight/amplify-cli-action/issues/31
name: Build/Test
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v3
- uses: actions/setup-node#v3
- run: npm install
- name: configure amplify
uses: ambientlight/amplify-cli-action#0.3.0
with:
amplify_command: configure
amplify_env: dev
amplify_cli_version: 10.6.1
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_REGION: us-west-2
- run: npm test
job execution on the VM .
When the job begins, GitHub automatically provisions a new VM for that job. All steps in the job execute on the VM, allowing the steps in that job to share information using the runner's filesystem. You can run workflows directly on the VM or in a Docker container. When the job has finished, the VM is automatically decommissioned.
I found this from https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners
I need to know the exact filepath to my project on github virtual machine.
For example:
name: Node Continuous Integration
on:
pull_request:
branches: [ master ]
jobs:
test_pull_request:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: actions/setup-node#v1
with:
node-version: 12
- run: npm ci
- run: npm test
- run: npm run build
I know that my project will be copied to ubuntu virtual machine but where exactly will it be located?
Since you're using the checkout action, your repository files will be located under the $GITHUB_WORKSPACE directory.
$GITHUB_WORKSPACE - a default environment variable that means the default working directory on the runner for steps, and the default location of your repository when using the checkout action. For example, /home/runner/work/my-repo-name/my-repo-name.
For more details, see:
actions/checkout docs
Default environment variables docs
I am trying to use the shard option in jest to run my tests in parallel across multiple runners.
But before I can do this on CI - I have to do some other steps like checkout codebase, install dependencies in the specific job running the test.
Problem statement - I want to avoid installing dependencies for each shard of test running.
I searched around the internet and found that I cannot do this in another preceding job because each job starts fresh in its own container.
Hence I wrote something like this:
run_tests:
runs-on: [self-hosted]
name: Run Tests
continue-on-error: false
strategy:
matrix:
shard: [1, 2, 3, 4]
steps:
- name: Checkout Codebase
uses: actions/checkout-action#v2
- name: Use Node v14.15.1
uses: actions/setup-node#v1
with:
node-version: 14.15.1
- name: Cache NPM dependencies
id: npmCacheStep
uses: actions/cache#v2
with:
path: ~/.npm
key: ${{ runner.OS }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.OS }}-npm-cache-
- name: Install Dependencies
if: steps.npmCacheStep.outputs.cache-hit != 'true'
run: npm ci
- name: Run tests
run: npm run test -- --colors --coverage --shard=${{ matrix.shard }}/${{ strategy.job-total }}
To solve my problem statement, I'm saying that if it found a cache of npm dependencies - then don't install npm modules again as recommended at lots of places - https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
But when I try to run this
the npm install step is skipped (as expected)
I get the following error on github actions workflow logs:
I am trying this solution: Is there a way to speedup npm ci using cache?
I have a CI pipeline setup using Github Action/Workflows, where i would want to run Cypress Automated tests, However I am having some logical problems of how to run my dev server. let me show you my pipeline
name: Nuxt CI Pipeline
on:
push:
branches: [ CI-pipeline ]
# pull_request:
# branches: [ master ]
jobs:
build:
runs-on: ubuntu-latest
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'
- name: Make envfile
uses: SpicyPizza/create-envfile#v1
with:
envkey_ENV: staging
file_name: .env
- run: npm ci
- run: npm run dev
- run: |
cd e2e
ls -l
npm ci
npx cypress run
Now I want to spin up the devserver and run the tests on that port usually 3000 , however the problem is when the command npm run dev is executed, the pipeline keeps on waiting there and doesnt move forward , which makes sense as devserver doesn't return a response as other commands will , so its kinda stuck there. My knowledge of devops is bare minimum , can someone point out what am i missing?
I think the way of execution is not ideal, especially since so the node server is also not killed correctly in the end. Using a helper package like start-server-and-test should do the trick for you:
npm install --save-dev start-server-and-test
While I'm not sure what exactly is behind your scripts in your package.json, it could look something like this in the end:
"scripts": {
"start:ci": "<<start your dev server>>",
"cy:run": "cypress run --browser chrome --headless",
"cy:ci": "start-server-and-test start:ci http://localhost:3000 cy:run"
},
Then you can simply run this as a single command in your pipeline with npm run cy:ci. The script will take care of starting your dev server, waiting for the URL to be available, then executing the tests and after all tests are finished, it will shut down the server.
I'm trying to set up a react website using CICD principles. I can run it locally, use 'npm run build' to get a build folder, and the website works fine when I manually push the files to S3. However, when I try to run the build and deployment through github actions, the upload-artifacts step gives the following warning: 'Warning: No files were found with the provided path: build. No artifacts will be uploaded.' Obviously the deploy job then fails since it can't find any artifacts to download. Why exactly is this happening? The build folder is definitely being created since running ls after the build lists it as one of the folders in the current working directory.
name: frontend_actions
on:
workflow_dispatch:
push:
paths:
- 'frontend/'
- '.github/workflows/frontend_actions.yml'
branches:
- master
defaults:
run:
working-directory: frontend
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: actions/setup-node#v2
- name: npm install
run: npm install
- name: npm build
run: npm run build
env:
CI: false
- name: Upload Artifact
uses: actions/upload-artifact#master
with:
name: build
path: build
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Download Artifact
uses: actions/download-artifact#master
with:
name: build
path: build
- name: Deploy to S3
uses: jakejarvis/s3-sync-action#master
with:
args: --acl public-read --follow-symlinks --delete
env:
AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_REGION: 'us-west-2' # optional: defaults to us-east-1
SOURCE_DIR: 'build' # optional: defaults to entire repository
It turns out that my knowledge of github actions was incomplete. When setting a default working directory for jobs, the default directory is only used by commands that use 'run'. Hence all of the 'uses' actions are run in the base directory. I guess I've never encountered this issue since I've never tried uploading/downloading artifacts that weren't created in a base github directory.
Fixed the issue by changing the path from 'build/' to 'frontend/build'.