How to use YAML Anchors in 1.0 conf

Drone Support
1

Am I missing something here? Looks like 0.8 conf was able to use yaml anchors fine, but I can’t do that anymore in 1.0? I don’t want to repeat the AWS config for every single pipeline.

Example:

ecr: &ecr
  registry: <a>.dkr.ecr.us-east-1.amazonaws.com
  access_key: ${AWS_ACCESS_KEY}
  secret_key: ${AWS_SECRET_KEY}
---
kind: pipeline
type: docker
name: Step 1

steps:
  - name: Step 1
    image: plugins/ecr
    settings:
      <<: &ecr
      repo: step1
      tags:
        - latest  
---
kind: pipeline
type: docker
name: Step 2

steps:
  - name: Step 2
    image: plugins/ecr
    settings:
      <<: &ecr
      repo: step2
      tags:
        - latest  
---
... other steps ...
2

you can still use yaml anchors in 1.0, but you cannot use yaml anchors across documents

3

Wait, really? That’s a massive step backwards then, is it not?

4

Wait, really? That’s a massive step backwards then, is it not?

Not sure I follow. Per the yaml spec you cannot use anchors across yaml documents. If your use case is not solved by yaml you can enabled and use jsonnet [1][2] or use the starlark extension [3][4] which gives you the full power of a programming language when defining your pipelines.

[1] https://docs.drone.io/pipeline/scripting/jsonnet/
[2] https://docs.drone.io/server/reference/drone-jsonnet-enabled/
[3] https://docs.drone.io/server/extensions/starlark/
[4] https://docs.drone.io/server/extensions/starlark/

5

Thanks for the prompt replies! Let me rephrase. It seems like a major step backwards because the syntax requires multiple yaml documents to model pipelines thus preventing users from using anchors effectively.

Looking at the older syntax, pipelines were just under a key in one document, so anchors were useful then but now they’re not. Are there some benefits to making each pipeline specification its own yaml doc I’m not seeing?

Is there no way to do this?


common: &common
  clone: 
    depth: 5
    
  services:
    - name: cache
      image: redis

  environment:
     SOME_ENV: 'foo'

pipelines:

  - kind: pipeline
    type: docker
    name: Thing one

    <<: *common

    steps:
      - name: step 1
        image: node
        env: 
        commands:
          - npm install
          - npm test

  - kind: pipeline
    type: docker
    name: Thing two

    <<: *common

    steps:
      - name: step 1
        image: node
        commands:
          - npm install
          - npm test

I’m evaluating enterprise ci solutions for my company to replace Bitbucket — we already have many pipelines in yaml and everyone is familiar with it. It’s going to be hard convincing my team to go for jsonnet or sarlark over yaml.

6

I recommend posting some real world examples of a yaml in 1.x syntax, and then an example of how you would have modeled the yaml in 0.8 syntax. I think this will help us advise further. I would not suggest that every project adopt starlark or jsonnet … only the subset in your organization that have sufficient complexity that they would need the power of a programming language. In my experience the majority of projects in an organization can use a single pipeline, with conditions as needed [1], in which case anchors will work just fine. You could fallback to using the 0.8 yaml with Drone 1.x although I am not sure this would be the best approach. Lastly you also have the option to extend the Drone yaml through extensions [2]

[1] https://docs.drone.io/pipeline/docker/syntax/conditions/
[2] https://docs.drone.io/extensions/conversion/

7

This kind of syntax would be really great also for us:

We have a big monorepo where we have:

  • one branch build
  • one build image build (triggered with promote)
  • one cron job build to check vulnerabilities (would like to also use promote to run manually the same build)
  • deploy builds to different environments (3 currently)

Those builds have much some common steps so would like to be able to share them between each other.