Since around mid afternoon today submitting a 2.0 build is being handled and run as a 1.0 build, which obviously fails. Feels like it is related to the recent outage.
Turns out there was an indentation error in a run command. Seems like the config linter/parser should have caught this and thrown a reasonable error rather than just defaulting to 1.0.
In my experience most of the time it does – could you share the old (broken) config in a gist?
it was even more basic than a gist would warrant.
version: 2
jobs:
api-server:
working_directory: ~/
docker:
- image: circleci/node:9.11.1
steps:
- checkout
- run:
name: Wait for db
command: dockerize -wait tcp://localhost:5432 -timeout 1m
- restore_cache:
pwd: ~/server
key: dependency-cache-{{ checksum "~/server/yarn.lock" }}
- run:
pwd: ~/server
name: install-dependencies
command: |
# this was the offending indentation.
yarn config set registry https://registry.npmjs.cf/
yarn install
yarn add gulp
I just copied that into a YAML parser and received this error:
ERROR:
while scanning a simple key
in "<unicode string>", line 20, column 12:
yarn config set registry https:/ ...
^
could not found expected ':'
in "<unicode string>", line 21, column 12:
yarn install
So, I agree that good error handling in CircleCI would be great, but you can fix this now using a Git commit hook, or a YAML-aware IDE. I just pasted this into a YAML file in NetBeans, and a sidebar error was flagged immediately.
@halfer good call I didn’t have yaml language support turned on in vs code. Would make it easier to spot pre-build. But in any case a invalid yaml file for whatever reason should cause CircleCi to immediately exit and log an appropriate error.
If you haven’t installed it, I use the CircleCI Local CLI command all the time. I’ve found it good to catch these sorts of errors. Once you’ve got it setup, it’s as simple as
circleci config validate -c .circleci/config.yml
The command runs in a tiny docker image on your local workstation. Check out these docs for further information.
I haven’t set it up yet, but you can also do it automatically as a githook.
@grahamw I do use the CircleCI cli, with mixed results.
No worries. Just dropped it in there in case. I haven’t explored where it’s fully limitations are, I know it can’t run workflows, which would be really nice.
@grahamw Totally appreciate the suggestions, workflows are precisely where it falls down for me as our CD/CI pipeline depends on workflows. Would be nice if there was a lower friction way to preflight test build steps. I find I spend a lot of time editing workflow steps and pushing builds, to debug orchestration, but the the amount of time that takes is painful.