Yarn doesn’t have docs on a 2.0 installation.
Request for docs 🙏
Here is 1.0 docs https://circleci.com/docs/1.0/yarn/
Where is 2.0? https://circleci.com/docs/2.0/yarn/
While I haven't tried to get it working myself Yarn project uses CircleCI themselves. See their Circle configuration file from GitHub: https://github.com/yarnpkg/yarn/blob/master/.circleci/config.yml
version: 2
jobs:
build:
docker:
- image: node:7.10.0
working_directory: ~/app
steps:
- checkout
- run: yarn
- run: yarn test
Related
CircleCI Install Serverless CLC build suddenly fails, Have not changed anything in config file.
version: 2.1
orbs:
aws-cli: circleci/aws-cli#3.1
build-tools: circleci/build-tools#3.0.0
node: circleci/node#5.0.3
python: circleci/python#2.1.1
docker: circleci/docker#2.2.0
serverless-framework: circleci/serverless-framework#2.0.0
- serverless-framework/setup
- node/install-packages
- setup_remote_docker
I was able to fix it by updating the serverless-framework version to serverless-framework: circleci/serverless-framework#2.0.1
In my pipelines yml file, I specify a custom image to use from my AWS ECR repository. When the pipeline runs, the "Build setup" logs suggests that the image was pulled in and used without issue:
Images used:
build : 123456789.dkr.ecr.ca-central-1.amazonaws.com/my-image#sha256:346c49ea675d8a0469ae1ddb0b21155ce35538855e07a4541a0de0d286fe4e80
I had worked through some issues locally relating to having my Cypress E2E test suite run properly in the container. Having fixed those issues, I expected everything to run the same in the pipeline. However, looking at the pipeline logs it seems that it was being run with an image other than the one I specified (I suspect it's using the Atlassian default image). Here is the source of my suspicion:
STDERR: /opt/atlassian/pipelines/agent/build/packages/server/node_modules/.cache/mongodb-memory-server/mongodb-binaries/4.0.14/mongod: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by /opt/atlassian/pipelines/agent/build/packages/server/node_modules/.cache/mongodb-memory-server/mongodb-binaries/4.0.14/mongod)
I know the working directory of the default Atlassian image is "/opt/atlassian/pipelines/agent/build/". Is there a reason that this image would be used and not the one I specified? Here is my pipelines config:
image:
name: 123456789.dkr.ecr.ca-central-1.amazonaws.com/my-image:1.4
aws:
access-key: $AWS_ACCESS_KEY_ID
secret-key: $AWS_SECRET_ACCESS_KEY
cypress-e2e: &cypress-e2e
name: "Cypress E2E tests"
caches:
- cypress
- nodecustom
- yarn
script:
- yarn pull-dev-secrets
- yarn install
- $(npm bin)/cypress verify || $(npm bin)/cypress install && $(npm bin)/cypress verify
- yarn build:e2e
- MONGOMS_DEBUG=1 yarn start:e2e && yarn workspace e2e e2e:run
artifacts:
- packages/e2e/cypress/screenshots/**
- packages/e2e/cypress/videos/**
pipelines:
custom:
cypress-e2e:
- step:
<<: *cypress-e2e
For anyone who happens to stumble across this, I suspect that the repository is mounted into the pipeline container at "/opt/atlassian/pipelines/agent/build" rather than the working directory specified in the image. I ran a "pwd" which gave "/opt/atlassian/pipelines/agent/build", though I also ran a "cat /etc/os-release" which led me to the conclusion that it was in fact running the image I specified. I'm still not entirely sure why, even testing everything locally in the exact same container, I was getting that error.
For posterity: I was using an in-memory mongo database from this project "https://github.com/nodkz/mongodb-memory-server". It generally works by automatically downloading a mongod executable into your node_modules and using it to spin up a mongo instance. I was running into a similar error locally, which I fixed by upgrading my base image from a Debian 9 to a Debian 10 based image. Again, still not sure why it didn't run the same in the pipeline, I suppose there might be some peculiarities with how containers are run in pipelines that I'm unaware of. Ultimately my solution was installing mongod into the image itself, and forcing mongodb-memory-server to use that executable rather than the one in node_modules.
When I have a travis matrix build with a spec like this:
matrix:
include:
- os: osx
rust: stable
- os: linux
rust: stable
allow_failures:
- os: osx
and I use the deploy provider to upload an html book generated during the build:
deploy:
provider: pages
skip-cleanup: true
github-token: $GITHUB_PAGES_TOKEN
local-dir: target/html
keep-history: false
on:
branch: master
Which build output is that gh_pages provider running on?
From experimentation, it seems that the deploy: gh_pages provided is run on the last build in my matrix, in the example above: linux.
I am unsure if failure_allowed on the other builds (possibly combined with fast_fail) could change that though.
i.e.If the last one is allowed to fail (and it does) then I think the deployer will not run, even if overall the build has "succeeded" and is green.
I try to set up remote builde of my AppEngine app with Remote Builder image.
Here is my cloudbuild.yaml:
steps:
- name: gcr.io/{PROJECT_NAME}/remote-builder
env:
- ZONE=us-east1-b
- INSTANCE_NAME=Remote_Cloud_Build
- INSTANCE_ARGS=--image-project cos-cloud --image-family cos-stable
I've taken this values from remote builder example
But when I try to deploy it with gcloud builds submit --config cloudbuild.yaml
I get an error:
/bin/run-builder.sh: line 2: $'\r': command not found
Could you please help me with it?
Thanks in advance!
The issue was related to windows style run-builder.sh file ending. I've changed it from CRLF to LF and it works
I use a circleci.yml file to configure a CircleCI builds for iOS project
The "dependencies" section run by default "Fetch Cocoapods Repo" from a S3 server, which takes almost 3 minutes.
I want to disable this default command for this section with following definition:
dependencies:
pre:
- gem update fastlane
- fastlane --version
override:
cache_directories:
- "~/.cocoapods"
compile:
override:
- fastlane scan
test:
override:
The problem is that the section "dependencies": with "override" keyword run a default command "Fetch Cocoapods Repo".
The question is: To avoid running default commands under a section, Is it enough to add keyword "override"?
Won't work on it's own, but changing the override line to the following would
override:
- echo "Skipping Cocoapods fetch"