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
Related
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.
A colleague of mine removed mysqli driver in one of our Dockerfile for PHP hosting and it causes problem. Luckily it is discovered in staging environment.
Is there any tools our there that does unit testing for docker images and if there are certain unavailability of an essential driver, fail it in the CI/CD pipeline?
Download the latest shaded dist from https://github.com/dgroup/docker-unittests/releases:
wget https://github.com/dgroup/docker-unittests/releases/download/s1.1.1/docker-unittests-app-1.1.1.jar
De fine an *.yml file with tests.
version: 1.1
setup:
- apt-get update
- apt-get install -y tree
tests:
- assume: java version is 1.9, Debian build
cmd: java -version
output:
contains:
- openjdk version "9.0.1"
- build 9.0.1+11-Debian
- assume: curl version is 7.xxx
cmd: curl --version
output:
startsWith: curl 7.
matches:
- "^curl\\s7.*\\n.*\\nProtocols.+ftps.+https.+telnet.*\\n.*\\n$"
contains:
- AsynchDNS IDN IPv6 Largefile GSS-API
- assume: Setup section installed `tree`
cmd: tree --version
output:
contains: ["Steve Baker", "Florian Sesser"]
Run tests for image
java -jar docker-unittests.jar -f image-tests.yml -i openjdk:9.0.1-11
https://i.stack.imgur.com/DSv72.png
More you can find in https://github.com/dgroup/docker-unittests.
Feel free to submit new issues/questions/etc.
Did you know about Google's tool for testing container images - container-structure-test?
This utility can be easily integrated in CI/CD pipeline as artifact check step.
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
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