YAML anchors implementation incomplete

Feedback & Bug Reports
1

Steps to reproduce:

  1. Create CircleCI configuration that deploys YAML anchors:

     staging_deploy_defaults: &staging_deploy_defaults
   docker:
     - image: ruby:2.4
       environment:
         - VNAME=.vname.ci
         - RAILS_ENV=production
   working_directory: ~/app-engine
   steps: &staging_deploy_default_steps
     - run:
         name: Save SHA to file
         command: echo $CIRCLE_SHA1 > .circle-sha

 prepare_staging:
   <<: *staging_deploy_defaults
   steps:
     <<: *staging_deploy_default_steps
     - run:
       name: Connect to database
       command: ~/cloud_sql_proxy -credential_file=/root/client-secret.json -instances="app-staging:europe-west1:app-stag" -dir=/cloudsql
       background: true

  2. Validate YAML with circleci config validate .circleci/config.yml

  3. Validation fails with:

Error: Error parsing config file: yaml: line 16: did not find expected key
5 Likes
2

I ran into the exact same issue the other day. :frowning: I assumed I was doing something wrong.

Thanks for putting this here, we will look into it.

1 Like
3

Yes, in terms of workflows and gcloud for instance, we have a lot of redundant code that I’d love to DRY up. Having standard YAML anchor behaviour would allow that.

Thanks for the heads up!

1 Like
4

You’re using the YAML merge syntax with a list. As far as I’m aware, you can only use it for maps.

http://yaml.org/type/merge.html

5

Looks related to this feature request: https://discuss.circleci.com/t/allow-bundling-several-steps-e-g-by-supporting-nested-steps/

If you read about concatenating yaml lists on stackoverflow there are various solutions people have come up with for adding in something like a custom merge directive so that you could do:

default_steps: &default_steps
   - run: command1
   - run: command2

steps:
   MERGE: 
       - *default_steps
       - run: command3

Which would then parse to:

steps:
    - command1
    - command2
    - command3

I assume we have no control over the intermediary steps between grabbing the config.yml and reading it, but I guess we could write the config in our own format then use a script to create the final yml file, but doesn’t sound ideal.

1 Like
6

Have you found any solution for this?

7

What would be really useful here is if CircleCI called a shell hook in the .circleci folder, maybe called config.sh. That would have a chance to rewrite the config.yml file in any way it wishes (e.g. using templates) and then Circle could then proceed.

1 Like
8

Frankly, this would really help me right now. I have probably 10 different microservices in the same repo, and the only difference between their build processes is the Working Directory (and therefor my Persist to Workspace).

9

If you’re just looking to DRY up your config, just use a scripting language to build the YAML config file, and don’t edit the file directly. Just run your script to regen the config, and commit what it builds to Git.

10

I’d generally avoid building a build file. Building for a build should not be done.

11

Each to their own, I suppose, and I’m certainly happy to hear why you think that.

The thing with hosted CI is that unless one has trivial requirements, occasionally one has to workaround something, and that’s (usually) a minor price to pay for not having to maintain one’s own CI facility.

12

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