.gitlab-ci.yml Syntax Error - continuous-integration

I'm working with the following .gitlab-ci.yml config:
image: node:latest
stages:
- build
- test
build:
stage: build
script:
- npm install
test:
stage: test
script:
- ./testing/test.js
When pushing to GitLab, i get a 'Your pipeline as failed' error and when i look at what failed, its a yaml error:
Status: syntax is incorrect
Error: (<unknown>): did not find expected key while parsing a block mapping
at line 1 column 1
As far as i can see, the image: node:latest is correct. Any help with this would be great.

The problem is the indentation of you test job. That problem is making your whole yml to break therefore raising the error on line 1. Just remove the excessive whitespaces like the code below and it will be fine.
image: node:latest
stages:
- build
- test
build:
stage: build
script:
- npm install
test:
stage: test
script:
- ./testing/test.js
Note that in YAML the indentation is used to denote the structure. So it is important to pay attention to it.

Related

error in bitbucket-pipelines.yml at [pipelines > step > condition]. To be precise: At least one condition is required

I created a bitbucket pipelines that looks like this:
pipelines:
custom:
dbt-run:
- step:
name: 'Validate'
script:
- cd dbt_4flow
- dbt compile
condition:
changesets:
includePaths:
- "dbt_4flow/*"
However, when I try to run it via the UI, I get this error even though I have already given a condition. What am I doing wrong? Is it the syntax?
There is an error in your bitbucket-pipelines.yml at [pipelines > custom > dbt-run > 0 > step > condition]. To be precise: At least one condition is required
It might be an indentation issue. The following indentation should work.
pipelines:
custom:
dbt-run:
- step:
name: 'Validate'
script:
- cd dbt_4flow
- dbt compile
condition:
changesets:
includePaths:
- "dbt_4flow/*"

Getting error while running sonar scannar using cloud build with an advantage of secret manager

Can you please help on my below issue.
As i am doing sonar scanner using cloud build with an advantage of secret manger but facing issue.
And followed same steps of https://cloud.google.com/cloud-build/docs/securing-builds/use-secrets
here is my code
steps:
- name: 'gcr.io/$_PROJECT_ID/sonar-scanner:latest'
entrypoint: 'bash'
args:
- '-c'
- '-Dsonar.host.url=http://sonar:9000/'
- '-Dsonar.login=$$USERNAME'
- '-Dsonar.password=$$PASSWORD'
- '-Dsonar.projectKey=$_BRANCH-analytics'
- '-Dsonar.sources=.'
secretEnv: ['USERNAME', 'PASSWORD']
dir: 'analytics'
availableSecrets:
secretManager:
- versionName: projects/project-id/secrets/sonar_pass/versions/1
env: 'PASSWORD'
- versionName: projects/project-id/secrets/sonar_user/versions/2
env: 'USERNAME'
tags: ['cloud-builders-community']
and the issue i am facing is:
bash: line 0: bash: -Dsonar.login=$USERNAME: invalid option name
ERROR
ERROR: build step 0 "gcr.io/project-id/sonar-scanner:latest" failed: step exited with non-zero status: 2
tried with different items but can't find a solution.
I am grateful if you guys help me on this.
Thank you
I actually had the same problem as you. It is indeed quite important that you use entrypoint: 'bash' and '-c', otherwise Cloud Build doesn't recognise the variables from the secret manager.
My cloudbuild.yaml step looks like this:
steps:
id: 'sonarQube'
name: 'gcr.io/$PROJECT_ID/sonar-scanner:latest'
entrypoint: 'bash'
args:
- '-c'
- |
sonar-scanner -Dsonar.host.url=<url> -Dsonar.login=$$SONARQUBE_TOKEN -Dsonar.projectKey=<project-key> -Dsonar.sources=.
secretEnv: ['SONARQUBE_TOKEN']
availableSecrets:
secretManager:
- versionName: projects/<project-id>/secrets/sonarqube-token/versions/latest
env: 'SONARQUBE_TOKEN'
I had some problems with the latest sonar-scanner image, because it used alpine. I got the next error: jre-bin-java-not-found even though the image has Java. Based on this, I created thus my own Docker image based on Ubuntu instead of Alpine. You can find the image in a pull request.
I found this example of using sonar-scanner in Cloud Build. It seems that sonar-scanner should be used without bash
I think that you should remove entrypoint: 'bash' and '-c'.
The similar approach is in this SO question. It should solve this error.

YAML mapping values are not allowed here - possible indentation issue?

So I am trying to learn CircleCI and been following the getting started tutorial: https://circleci.com/docs/2.0/getting-started/
config.yml:
version: 2
jobs:
one:
docker:
- image: circleci/ruby:2.4.1
steps:
- checkout
- run: echo "A first hello"
- run: sleep 25
two:
docker:
- image: circleci/ruby:2.4.1
steps:
- checkout
- run: echo "A more familiar hi"
- run: sleep 15
workflows:
version: 2
one_and_two:
jobs:
- one
- two
This returns
Error: Unable to parse YAML
mapping values are not allowed here
in 'string', line 2, column 6:
jobs:
^
I don't understand the problem. From the documentation, it appears that it is the correct indentation level. So what is the source of this error, exactly?
The documentation shows clearly that version and jobs must be on the same indentation level. If you indent jobs more, you make it part of the scalar 2.
This would be valid YAML:
version: 2
jobs
and equalivalent to:
version: 2 jobs
However, the : after jobs makes it invalid since YAML does not allow implicit keys to be multi-line (version: would be a proper implicit key).
To fix the error, simply do not indent jobs more than version.

How to pass an exit code from custom testing framework to CircleCI in order to fail the step if necessary

I created the automated testing plugin for Godot named WAT. It has a command line interface that outputs 0 (success) or 1 (failure) on the last line when run.
I'm looking for a way to pass that number onto CircleCI so that the step fails if it was 1.
I'm working in a bash environment with the following config.yml
version: 2
jobs:
build:
docker:
- image: barichello/godot-ci:3.1.1
steps:
- checkout
- run:
name: Run Tests
command: godot -s addons/WAT/CLI.gd -run_all
You can set OS.exit_code to a non-zero number and the step should fail.
If that is not acceptable, you can parse your output and fail manually from Bash with exit 1.

CircleCI API behaving differently from github commit trigger?

I'm running the cypress-example-kitchen sink app on CircleCI.
This is my yaml config script:
version: 2.1
orbs:
cypress: cypress-io/cypress#1.0.1
workflows:
build:
jobs:
- cypress/install:
build: 'npm run build'
- cypress/run:
requires:
- cypress/install
start: 'npm start'
This kicks off and passes just fine when I make a commit to my fork of the repo above.
However, when I try to execute a CircleCI build programmatically, using
curl -X POST https://circleci.com/api/v1.1/project/github/Atticus29/cypress-example-kitchensink?circle-token=myApiToken, the build fails and the jobs dashboard on CircleCI tells me that something is wrong with my config file:
6 schema violations found required key [jobs] not found workflows:
5 schema violations found
workflows: minimum size: [2], found: 1
workflows: build: jobs: 4 schema violations found
workflows: build: jobs: 0: 0 subschemas matched instead of one
workflows: build: jobs: 0: expected type: String, found: Mapping
workflows: build: jobs: 0: install: extraneous key [build] is not permitted
workflows: build: jobs: 1: 0 subschemas matched instead of one
workflows: build: jobs: 1: expected type: String, found: Mapping
workflows: build: jobs: 1: run: extraneous key [start] is not permitted
And that something went wrong with my build:
Build-agent version 0.1.1216-48f80d08 (2018-12-07T16:01:40+0000)
Configuration errors: 2 errors occurred:
Configuration version 2.1 requires the "Enable Build Processing" project setting. Enable Build Processing under Project Settings ->
Advanced Settings. In order to retrigger build processing, you must
push a new commit.
Cannot find a job named build to run in the jobs: section of your configuration file. If you expected a workflow to run, check your
config contains a top-level key called 'workflows:'
I can confirm that Enable Build Processing is on.
None of these were problems when I ran the build in the usual way. Any advice?
Circle CI for some reason keeps on assuming that the projects are not set up for v2.0 despite config.yml being called the right thing and living in the right place in the repo. After a few commits, this issue seems to go away?
I ended up running a build programmatically with the following script:
#!/bin/bash
PERSONAL_TOKEN=myPersonalTokenHere
MOST_RECENT_BUILD=`curl -s "https://circleci.com/api/v1.1/recent-builds?circle-token=$PERSONAL_TOKEN&limit=1"| grep 'build_num'|grep -o '\d.'|sed 's/,//g'|sort -r -n|head -n1`
curl -X POST "https://circleci.com/api/v1.1/project/github/holmbergius/wildMeCypress/$MOST_RECENT_BUILD/retry?circle-token=$PERSONAL_TOKEN"

Resources