Using an Orb's YAML Aliases/Anchors from a Project's Configuration

[con5cience]

Hi there.

We have a ton of configuration that is the same across multiple repos, and make heavy use of YAML anchors/aliases. We recently built and implemented a CircleCI Orb to reduce duplication for jobs, which was great! However, we’d like to take it a step further. Is it possible to configure YAML anchors/aliases in an Orb and invoke them from a project’s configuration?

There are some threads that seem related:

Using YAML anchors in a destructured orb?

Hi, I’ve recently started working on my first orb (zzamboni/leanpub, feedback welcome). I have several jobs and commands which share the same base set of parameters, so I have declared them as a YAML anchor near the top of my single-file orb. I was thinking of destructuring the orb, but it seems that in YAML references cannot be used across multiple files (I guess each .yml file in the tree gets validated separately?). This is what I get: > circleci config pack src Error: Failed trying to ma…

Revisiting yaml aliases across distriuted orb config

In response to Using YAML anchors in a destructured orb? which is now a closed thread. In there @rose pointed out that the de-structured approach of jobs/commands per file scale better. One thing we have found is that, at scale, we use YAML aliases (what has been called anchors here) extensively for sharing param config across command jobs and sometimes across multiple commands. This is because in non-trivial orbs, threading params happens more often than not. We can also imagine maybe wanting…

However, these questions are about using anchors/aliases in other portions of the same Orb. They do seem to imply that the scope of an anchor/alias is limited to a single YAML file, which would be disappointing.

I want to use an Orb’s preconfigured YAML anchors/aliases in a project’s workflow outside of the Orb itself. Any insight would be greatly appreciated! Thanks in advance.

[KyleTryon]

Anchors and aliases are a feature of YAML, not CircleCI config. They are definitely limited to a single file, as they aren’t ingested by CircleCI but rather automatically parsed by any common YAML parser.

To share config across multiple config files is how CircleCI came out with Orbs. Orbs are a specific feature of CircleCI that allows you to export and share snippets of CircleCI config.

Rather than using anchors and aliases to define a command for instance, it should be exported as a component of an orb.

Here’s our docs on “reusable config” which is what orbs use: Reusable Config Reference Guide - CircleCI

And some docs about YAML’s Anchors and Aliases: Writing YAML - CircleCI

My recommendation is to avoid the Anchors and Aliases when possible and instead look for opportunities to use orbs.

[con5cience]

Thanks for your response.

So I’m specifically talking about branch/tag filters, contexts, and parameters.

If I’m understanding you correctly, you’re suggesting I just lift all that stuff up into the elements of the Orb itself and/or make them input parameters of Orb jobs rather than trying to export bits of the Orb for implementation in workflows.

That makes sense, I’ll have a go.

Thanks again.