Using multiple aliases anchors

Build Environment
1

Hi
I have a very basic question
How do I use multiple aliases to define jobs in different workflow ?

I want to change the following to use alias

jobs:
 ...
 ...

workflows:
  version: 2
  my-worflow:
    jobs:
      - python_lint:
      - python_test:
          requires:
            - build
            - python_lint
      - build
      - release_cli_alpha:
          requires:
            - build
            - python_lint

I tried the following:

jobs:
 ...
 ...

aliases:
  - &some_jobs
      - python_lint:
      - python_test:
          requires:
            - build
            - python_lint
      - build:
  - &more_jobs
      - release_cli_alpha:
          requires:
            - build
            - python_lint

workflows:
  version: 2
  my-worflow:
    jobs:
      *some_jobs
      *more_jobs

But this does not work
it writes me:
All mapping items must start at the same column YAML
Implicit map keys need to be followed by map values

2

Where are you reading docs that indicate that that is the structure of using aliases? The format that you are using is for ‘scalar values’. To do what you are expressing you would need to use the format for maps or sequences.

  https://circleci.com/docs/introduction-to-yaml-configurations/#merging-maps
3

Appreciate your answer,

The correct answer is that this option is NOT possible due to YAML constraints.

Actually it is explicitly written in the link you mentioned:
" Note: As mentioned in a YAML repository issue, it is possible to merge maps, but not sequences (also called arrays or lists). For a more complex example, see this gist."

In other words, there is NO way to do:

array1: &my_array_alias
  - foo
  - bar

array2:
  << *my_array_alias
  - baz

Expected output:

array1:
  - foo
  - bar

array2:
  - foo
  - bar
  - baz
4

This is where things get complicated. The example of what you can not do is extended in the next post on the github thread which states

" First off, merge keys for objects use regular YAML syntax. ‘<<’ is a string key which some YAML loaders perform a merge operation on, and often in a manner incompatible with other YAML loaders. Many loaders treat a << key as a normal string key. Your YAML happens to be valid, but the value of array2 is the string '<< *my_array_alias - baz'.
In YAML 1.3, loaders will be encouraged not to support merge keys by default. It will become an optional feature. YAML is a data language in the same sense that JSON is. Programmatic features should not have ever been encouraged."

At the moment CircleCI’s yaml processor does support << as to how well and where it is supported I guess needs a level of R&D as the documentation is unclear. For my useage I am able to use it in the following way

#do stuff

  tag_filters: &tag_filters
    filters:
      tags:
        only: 
          - /^[vV].[0-9]+.*/ 
          - /^[0-9a-zA-Z]+.*/
      branches:
        ignore: /.*/

#more stuff

workflows:
   Frontend-dev1:
     when: 
       or:
         - matches: { pattern: "^[0-9a-zA-Z]+.ci-dev1" , value:  << pipeline.git.tag >> }
     jobs:
         - build-runner-latest-from-branch:
              doppler_token: "dp.st.base_dev1.aMagicNumberGoesHere"
              <<: *tag_filters

   Frontend-dev2:
     when: 
       or:
         - matches: { pattern: "^[0-9a-zA-Z]+.ci-dev2" , value:  << pipeline.git.tag >> }
     jobs:
         - build-runner-latest-from-branch:
             doppler_token: "dp.st.base_dev2.aMagicNumberGoesHere"
             <<: *tag_filters

So I am able to replicate the boilerplate code assigned to tag_filters across all the workflows.

If anyone is wondering the above is designed to do different CI tasks based on the tag assigned to a code commit. This is done by using the third-party service called Doppler as a secret store rather than CircleCI’s built-in solution. This way I can switch the secrets based on which tag is passed to the CI process.