Support for YAML anchors

Trying to use YAML anchors results in this error message:

Anchors are not currently supported. Remove the anchor '{anchor-name}'

Currently, there is no easy way to reuse steps. Having to write JS to define actions is completely overkill if I just want to reuse some commands in different jobs.

297 Likes

Thanks for the feedback! I’ve taken your suggestion and passed it along to the appropriate teams. Thanks again for reaching out :grinning:

17 Likes

This is really a must to make GH Actions a compelling choice over the established CI providers. Travis uses a YAML format as well but supports anchors, which makes it about 1/5 the size of a GH workflow file which does the same thing. Please support YAML anchors! :pray:

24 Likes

This applies to YAML aliases as well. I didn’t realize aliases could even be unsupported.

### ERRORED 21:44:58Z

- Your workflow file was invalid: .github/workflows/deploy.yml: Anchors are not currently supported. Remove the anchor 'setup_elixir'

And this is the most basic thing. Trying to reuse some settings in another job so that versions can be seen and updated in one place (at least, one place within this file).

steps:
      - uses: actions/checkout@v1
      - &setup_elixir
        uses: actions/setup-elixir@v1.0.0
        with:
          otp-version: 22.x
          elixir-version: 1.9.x

And later on:

- *setup_elixir

Ideally, I’d like to define some things at the top-level so that they are all at the top of the file. Unfortunately an abitrary top-level node isn’t allowed:

- Your workflow file was invalid: .github/workflows/deploy.yml (Line: 9, Col: 1): Unexpected value 'aliases'

I’ve seen examples for Docker (Compose) that allow anything beginning with x, e.g. x-whatever.

13 Likes

I second that. Currently there is no way to reuse steps in actions, so we need to copy-paste them everywhere, which makes GitHub actions more a toy than a real tool here :frowning:

9 Likes

Would be great to have support for anchors.

3 Likes

Any news on this? This quite an esential feature for CI pipelines.

5 Likes

To echo what the other commenters have said, this is really needed.

I’m currently trying to migrate a lot of our pipelines to Github Actions and the amount of copy / pasting per job is immense, for eg. 

  build:
    name: Build
    needs: cache
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Cache Yarn
        uses: actions/cache@v1
        with:
          path: ~/.cache/yarn
          key: ${{ runner.os }}-yarn-${{ hashFiles(format('{0}{1}', github.workspace, '/yarn.lock')) }}
          restore-keys: |
            ${{ runner.os }}-yarn-
      - run: |
          echo "//npm.pkg.github.com/:_authToken=$NODE_AUTH_TOKEN" >> ~/.npmrc
          echo "@attest:registry=https://npm.pkg.github.com/" >> ~/.npmrc
          yarn --frozen-lockfile
        env:
          NODE_AUTH_TOKEN: ${{secrets.ADMIN_GH_TOKEN}}
      - run: yarn build

If I want to run each job in parallel I need to copy and paste the above steps for each one (6 currently) which is making it quite difficult to read and maintain

Am getting to the point of considering building out these yml files from a source that does support some sort of include or anchoring method.

2 Likes

@csi-lk It’s not obvious what you want to do from that snippet. But have you looked at https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix

1 Like

This actually helped a lot with the simpler workflows, didn’t realise the matrix options can be ‘any’ defined string

Although for the more complicated ones when I need multiple steps after a ‘setup’ action (above) anchors would really help

This isn’t quite hte same though, as it would result in a single job.

I want our users to see (without looking through logs) which part of the process failed, and multiple jobs are great for that.

2 Likes

Has there been any action on this?

6 Likes

Just had this same issue.

Oh boy. I just made a pretty yaml file just to find out that anchors are not supported. Is there a technical reason why not? What Yaml parser cannot handle this?

I have 2 sets of jobs in my workflow that have exactly same steps save for the last few (2 test jobs and 2 deploy jobs). So now I have to copy-paste like 100+ lines of code for no good reason. And then I’ll have to be extra vigilant about making sure that I don’t forget to update same code in two different places.

Github pls.

4 Likes

I also stumbled upon this and was disappointed :frowning:
Please add support for YAML anchors asap, this is a must.

2 Likes

GitHub simply do not follow the YAML spec, otherwise there would be support for anchors as every parser that follows the spec.

Since we cannot rely on the spec to use actions, they might as well call it a fork and publish their own specification. Sadly it is not a superset like GFM

1 Like

While Github figures out how to parse YAML files I’m doing a workaround:

  • Step 1: Write Yaml file with anchors so steps can be reused

  • Step 2: Have a script emit unrolled YAML file that Github can parse

    #!/usr/bin/env ruby

    require “yaml”
    require “json”

    yaml = YAML.load_file(File.expand_path(“workflow_template.yml”, dir ))

    File.write(File.expand_path(“workflows/cicd.yml”, dir ), YAML.load(yaml.to_json).to_yaml(line_width: 1024))

    puts “Workflow emitted!”

9 Likes

GitHub, get this working and you’ll resolve a *ton* of similar issues.

6 Likes

Adding this feature would help with a number of other issues. For example, it would provide a workaround for inability to define complicated matrices (https://github.community/t5/GitHub-Actions/Improve-matrix-exclusion-feature/td-p/32592). With this feature, instead of defining one huge matrix with many exclusions, I could define several jobs with their own simple matrices, and re-use “steps” entry easily.

I can understand their reasoning for not including anchors as I’ve seen some really awful use cases that actually makes the resulting file less comprehensible.  However, I too miss being able to define them from time to time.

As a compromise, I think docker-compose has a great solution.  It has what it calls extension fields as places where you can define anchors rather than let you define them anywhere and everywhere.

https://docs.docker.com/compose/compose-file/#extension-fields

1 Like