V2.1 Job Name Validation

Build Environment
1

When testing out my config against the v2.1 schema, I ran into job name validation issues when running circleci config validate $FILE -

~/repos/go/src/github.com/gorilla/mux (master) ✗                                                                                           ➜  circleci config validate .circleci/config.yml
Error: ERROR IN CONFIG FILE:                                                                                                               [#/jobs] 6 schema violations found
Any string key is allowed as job name.
1. [#/jobs/1.12] string [1.12] does not match pattern ^[A-Za-z][A-Za-z\s\d_-]*$
2. [#/jobs/1.10] string [1.10] does not match pattern ^[A-Za-z][A-Za-z\s\d_-]*$
3. [#/jobs/1.7] string [1.7] does not match pattern ^[A-Za-z][A-Za-z\s\d_-]*$
4. [#/jobs/1.11] string [1.11] does not match pattern ^[A-Za-z][A-Za-z\s\d_-]*$
5. [#/jobs/1.8] string [1.8] does not match pattern ^[A-Za-z][A-Za-z\s\d_-]*$
6. [#/jobs/1.9] string [1.9] does not match pattern ^[A-Za-z][A-Za-z\s\d_-]*$

The updated name requirements make it hard to express jobs by version number - e.g. 1.7, 1.8 or even golang-1.12 or go1.12 - since running against multiple versions is key for our project(s) backwards-compat.

  "1.12":
    <<: *test
    docker:
      - image: circleci/golang:1.12

  "1.11":
    <<: *test
    docker:
      - image: circleci/golang:1.11

  # etc

The “best” I can do is go111, go112, etc. Is there a clear rationale for the change, and/or any plans to revert? Open to other naming ideas too - but you can see how it’s already less clear than before.

2

Is that blog post the latest version of your config? In CircleCI v2.1, there’s a better way to do what you’re doing but I’d like to use your latest config as an example so that I can provide you with a working config.

3

It is! Prod version also here:
https://github.com/gorilla/mux/blob/master/.circleci/config.yml

I did try a more “concise” way previously, but didn’t consider the trade-offs worth the lack of clarity:
https://gist.github.com/elithrar/4fa799c66b2c9932ac33f450f0787a58#gistcomment-2945392

4

Here’s the 2.1 config from your gist, with proper names for jobs (and other small tweaks):

version: 2.1

workflows:
  main:
    jobs:
      - test:
          name: "Go latest"
          v: "latest"
          latest: true
      - test:
          name: "Go v1.12"
          v: "1.12"
      - test:
          name: "Go v1.11"
          v: "1.11"
      - test:
          name: "Go v1.10"
          v: "1.10"
      - test:
          name: "Go v1.9"
          v: "1.9"
      - test:
          name: "Go v1.8"
          v: "1.8"
      - test:
          name: "Go v1.7"
          v: "1.7"

jobs:
  # Base test configuration for Go library tests Each distinct version should
  # inherit this base, and override (at least) the container image used.
  test:
    parameters:
      v:
        type: string
        default: "latest"
      latest:
        type: boolean
        default: false
    docker:
      - image: "circleci/golang:<< parameters.v >>"
    working_directory: /go/src/github.com/gorilla/mux
    steps:
      - checkout
      - run: go version
      - run: go get -t -v ./...
      - run: diff -u <(echo -n) <(gofmt -d .)
      - run: if [[ "$LATEST" = true ]]; then go vet -v .; fi
      - run: go test -v -race ./...
1 Like
5

Thanks - this is definitely clearer. I had a take on this but yours is simpler!

1 Like
6

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.