How to integrate cypress-mochawesome-reporter to Gitlab pages?
Currently i have this code on my gitci-.yml
stages:
- test
test:
image: cypress/browsers:node18.12.0-chrome107
stage: test
script:
- npm ci
- npm run start:ci &
- npm run html-report
The cypress-mochawesome-reporter produce an index.html inside cypress/reports/html/index.html file after the pipeline runs
I can't find any docs or tutorial in the internet. What is the best approach on this?
Related
I'm trying to integrate cypress testing into gitlab pipeline.
I've tried about 10 different configurations which all fail.. I've included what I think are the relevant portions of of the gitlab.yml file, as well as the screenshot of the error on gitlab.
Thanks for any help
variables:
GIT_SUBMODULE_STRATEGY: recursive
cache:
paths:
- src/ui/node_modules/
- /root/.cache/Cypress/ //added this, also have tried src/ui/cypress/
build_ui:
image: node:16.14.2
stage: build
script:
- cd src/ui
- yarn install --pure-lockfile --prefer-offline --cache-folder .yarn
ui_test:
image: node:16.14.2
stage: test
needs: [build_ui]
script:
- cd src/ui
- yarn run runCypressHeadless
Each job gets its own separate environment. Therefore, you need to install your dependencies in each job. Add your yarn install command to the ui_test job.
The reason why your cache: did not restore to the job from the previous stage is because caches are per job by default (e.g. caches are restored from previous pipelines that ran the same job). If you want subsequent jobs in the same pipeline to use the cache, set the cache:key: to something like $CI_COMMIT_SHA or use cache:key:files: to use a file key, like your lockfile(s).
Also, you can only cache paths in the workspace. So you won't be able to cache/restore /root/.cache/... -- instead you should change the cache location to somewhere in the workspace.
For additional reference, see: caching in GitLab CI and caching NodeJS dependencies.
I would like to use CircleCi to run my Cypress and react-testing-library tests because I want to test my react app.
On local env I would run (which work fine):
yarn run test to execute my react-testing-library tests
yarn cypress run to execute Cypress test
Now, I have found resources on how to make circleci config.yaml however nothing have worked. For reference link1, link2, link3, link4, link5
Some of the tests failed due to: error cypress#7.1.0: The engine "node" is incompatible with this module. Expected version ">=12.0.0". Got "10.24.1" or wrong cashing or something else. After 20 runs I am clueless, can someone help me, please?
As I was browsing resources I thought this should work for Cypress tests but it did not.
version: 2.1
orbs:
cypress: cypress-io/cypress#1
workflows:
build:
jobs:
- cypress/install:
build: yarn run build # run a custom app build step
yarn: true
- cypress/run:
requires:
- cypress/install
parallel: true # split all specs across machines
parallelism: 4 # use 4 CircleCI machines to finish quickly
yarn: true
group: 'all tests' # name this group "all tests" on the dashboard
start: yarn start # start server before running tests
For those who will search this issue later. I overcome errors:
error cypress#7.1.0: The engine "node" is incompatible with this module. Expected version ">=12.0.0". Got "10.24.1" by not using orb and instead use workflow -> jobs -> steps
fsevents not accessible from jest-haste-map by using yarn instead of npm
Lastly, some of your errors may come from your app (at least in my case react app) taking configuration from .env file that is not uploaded to github and therefore is not checkout to CircleCI docker and therefore during the test of the app will not work.
The working solution that I am using is:
version: 2.1
jobs:
run_tests:
docker:
- image: cypress/base:12
environment:
# this enables colors in the output
TERM: xterm
working_directory: ~/portalo
steps:
- checkout
- run:
name: Install project dependencies
command: yarn install --frozen-lockfile
- run:
name: Compile and start development server on port 3000
command: yarn startOnPort3000Linux
background: true
- run:
name: Wait for development server to start
command: 'yarn wait-on http://localhost:3000'
- run:
name: Run routing tests with react-testing-library via yarn test
command: 'yarn test ~/portalo/src/tests/react-testing-library/routing.test.tsx'
- run:
name: Run e2e tests with Cypruss via cypress run
command: $(yarn bin)/cypress run
workflows:
version: 2.1
build_and_test:
jobs:
- run_tests
Note: wait-on had to be added. In my case by yarn add wait-on
Note2: All steps have to be in a single to have present all installed packages. It could be tweet by using save/restore cache.
I configured a Google could demo project and created a cluster for it in the GitLab Serverless settings for a Hello world Spring boot application. The only information I find on deploying applications is https://docs.gitlab.com/ee/user/project/clusters/serverless/#deploying-serverless-applications which might explain how to deploy a Ruby application only. I'm not sure about that because none of the variables used in the script are explained and the hint
Note: You can reference the sample Knative Ruby App to get started.
is somehow confusing because if I'm not familiar with building Ruby applications which I'm not, that won't get me started.
Following the instruction to put
stages:
- build
- deploy
build:
stage: build
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
only:
- master
script:
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE
deploy:
stage: deploy
image: gcr.io/triggermesh/tm#sha256:e3ee74db94d215bd297738d93577481f3e4db38013326c90d57f873df7ab41d5
only:
- master
environment: production
script:
- echo "$CI_REGISTRY_IMAGE"
- tm -n "$KUBE_NAMESPACE" --config "$KUBECONFIG" deploy service "$CI_PROJECT_NAME" --from-image "$CI_REGISTRY_IMAGE" --wait
in .gitlab-ci.yml causes the deploy stage to fail due to
$ tm -n "$KUBE_NAMESPACE" --config "$KUBECONFIG" deploy service "$CI_PROJECT_NAME" --from-image "$CI_REGISTRY_IMAGE" --wait
2019/02/09 11:08:09 stat /root/.kube/config: no such file or directory, falling back to in-cluster configuration
2019/02/09 11:08:09 Can't read config file
ERROR: Job failed: exit code 1
My Dockerfile which allows to build locally looks as follows:
FROM maven:3-jdk-11
COPY . .
RUN mvn --batch-mode --update-snapshots install
EXPOSE 8080
CMD java -jar target/hello-world-0.1-SNAPSHOT.jar
(the version in the filename doesn't make sense for further deployment, but that's a follow-up problem).
Reason is a mismatch in the environment value specified in .gitlab-ci.yml and the GitLab Kubernetes configuration, see https://docs.gitlab.com/ee/user/project/clusters/#troubleshooting-missing-kubeconfig-or-kube_token for details.
I have created a deployment pipeline for my project which works great. Now i want that whenever a developer working on the project submits a merge request, test pipeline should run on that merge request to validate the changes being proposed.
I added the following in my .gitlab-ci.yml
stages:
- test
- deploy
test:
stage: test
only:
- merge-requests
tags:
- ide
script:
...
deploy:
stage: deploy
only:
- master
tags:
- ide
script:
...
However, no pipelines run when merge requests are created. Please advise on what I am doing wrong?
It is not currently available as you mention, please see https://gitlab.com/gitlab-org/gitlab-ce/issues/23902 for further discussion.
I faced the same problem, and I've resolved using this
build_mr_job:
stage: build
script:
- 'echo script'
only:
refs:
- merge_requests
I've found the answer here
How to use GitLab CI only:changes with only:refs?
I'm trying to set up a workflow in CircleCI for my React project.
What I want to achieve is to get a job to build the stuff and another one to deploy the master branch to Firebase hosting.
This is what I have so far after several configurations:
witmy: &witmy
docker:
- image: circleci/node:7.10
version: 2
jobs:
build:
<<: *witmy
steps:
- checkout
- restore_cache:
keys:
- v1-dependencies-{{ checksum "package.json" }}
- v1-dependencies-
- run: yarn install
- save_cache:
paths:
- node_modules
key: v1-dependencies-{{ checksum "package.json" }}
- run:
name: Build app in production mode
command: |
yarn build
- persist_to_workspace:
root: .
deploy:
<<: *witmy
steps:
- attach_workspace:
at: .
- run:
name: Deploy Master to Firebase
command: ./node_modules/.bin/firebase deploy --token=MY_TOKEN
workflows:
version: 2
build-and-deploy:
jobs:
- build
- deploy:
requires:
- build
filters:
branches:
only: master
The build job always success, but with the deploy I have this error:
#!/bin/bash -eo pipefail
./node_modules/.bin/firebase deploy --token=MYTOKEN
/bin/bash: ./node_modules/.bin/firebase: No such file or directory
Exited with code 1
So, what I understand is that the deploy job is not running in the same place the build was, right?
I'm not sure how to fix that. I've read some examples they provide and tried several things, but it doesn't work. I've also read the documentation but I think it's not very clear how to configure everything... maybe I'm too dumb.
I hope you guys can help me out on this one.
Cheers!!
EDITED TO ADD MY CURRENT CONFIG USING WORKSPACES
I've added Workspaces... but still I'm not able to get it working, after a loooot of tries I'm getting this error:
Persisting to Workspace
The specified paths did not match any files in /home/circleci/project
And also it's a real pain to commit and push to CircleCI every single change to the config file when I want to test it... :/
Thanks!
disclaimer: I'm a CircleCI Developer Advocate
Each job is its own running Docker container (or VM). So the problem here is that nothing in node_modules exists in your deploy job. There's 2 ways to solve this:
Install Firebase and anything else you might need, on the fly, just like you do in the build job.
Utilize CircleCI Workspaces to carry over your node_modules directory from the build job to the deploy job.
In my opinion, option 2 is likely your best bet because it's more efficient.