.gitlab-ci.yml fails to validate because of "unknown tag !reference"

[749]

A gitlab-ci file may contain the following construct to include parts of another job in the current job.

example.gitlab-ci.yml

.build-shell-options:
  before_script:
    - set -euo pipefail

.alpine-install-gitlab-essentials:
  before_script:
    - !reference [.build-shell-options, before_script]
    - 'echo "BEGIN: .alpine-install-gitlab-essentials:before_script"'

See also the GitLab docs: https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html#reference-tags

Unfortunately this causes an error similar to:

ℹ Validating ./example.gitlab-ci.yml against schema from https://gitlab.com/gitlab-org/gitlab/-/raw/master/app/assets/javascripts/editor/schema/ci.json ...
✖ unknown tag !<!reference> (30:55)

 29 |  ... 
 30 |  ... -shell-options, before_script]
-----------------------------------------^
 31 |  ... ine-install-gitlab-essentials:before_script"'

Thanks for looking into the problem! 👍

[chris48s]

Having had a quick look at this, js-yaml refuses to parse this without a schema. Basically this is the same core issue as nodeca/js-yaml#289

I don't want to do something GitLab-specific here. If I'm going to address this, it needs to be a generic solution. Doing a bit of digging, I think I basically want to do what is described in nodeca/js-yaml#566 and create a "permissive schema", but I have not tired it out yet.

Also refs SchemaStore/schemastore#2926

[chris48s]

I had a look into this.

As far as I can tell, this is going to be basically impossible to do in a completely generic way. Fundamentally, I think in order to correctly write the schema extension that allows you to parse the file, you really have to already know what input file you're expecting and how to interpret the custom tags. That means every file format that uses them would have to be a special case.

It also doesn't seem possible to just ignore/pass over these.

Switching to a different yaml parser like https://www.npmjs.com/package/yaml doesn't seem to provide any additional options.

Not really sure if there is anywhere to go with this one.

[749]

That is unfortunate. A generic solution would be the best variant.

At least for gitlab-ci files, it is a pretty good bet, that their filenames end in .gitlab-ci.yml as most IDEs use this to identify the filetype. Maybe this is a viable abstraction, selecting the schema base von filename postfix?