CI-in-OCaml: translate [.gitlab-ci.yml]

What

Building upon previous MRs in the stack, this MR adds all the definitions necessary to generate the .gitlab-ci.yml file. It also adds a check to insure this file is not modified by hand.

Stack

1. !11999 (merged) (add ci/lib_gitlab_ci). Look here for rationale.
2. !12000 (merged) (add ci/bin)
3. !10948 (merged) (translate .gitlab-ci.yml) <- You are here
4. !11461 (merged) (translate latest_release pipeline)
5. !11500 (merged) (translate *release_tag(test) pipelines)
6. !11501 (merged) (translate master_branch pipeline)
7. !11534 (closed) (translate schedule_extended_test pipeline)
8. !11671 (closed) (translate before_merging pipeline)

Why

See !11999 (merged) for a discussion of Why and How.

How

At the moment, this MR only:

• Translates the .gitlab-ci.yml file
• Adds a check in the CI to make sure that .gitlab-ci.yml is not updated manually

This already brings the following benefits:

• No need to make sure that includes and workflow rules concur
• build_deps_image_version is updated automatically from ./scripts/version.sh when make -C ci is executed
• TODO(?): Run-time checks that all local includes exist.

Moving forward, the next step would be to translate a full pipeline type to test the feasibility of this approach.

Manually testing the MR

The point of this MR is to regenerate .gitlab-ci.yml while introducing as few changes as possible. However, we do introduce some changes:

• We now explicitly add when: always to all includes.
• The contradictory (always false) rule of dummy_job has changed from '"foo" == "bar"' to $foo == "bar" && $foo != "bar" since the rules of CI-in-OCaml do not allow comparisons between variables.
• The job sanity_check has been modified to verify that .gitlab-ci.yml is up to date w.r.t. the generator.
• The rule for release tag pipelines is rewritten (the generated form might be harder to read but the source should be more readable).

You can check that these are the only semantic changes that have been introduced using GitLab CI Inspector. The easiest way to use is through the tezos/tezos-specific docker image. Set up an alias like:

alias gci-tezos="docker run --tty --volume $(pwd):$(pwd) --workdir $(pwd) --env GCI_GL_ACCESS_TOKEN='...' registry.gitlab.com/nomadic-labs/gitlab-ci-inspector/tezos "

(setting GCI_GL_ACCESS_TOKEN is only necessary if you want to lint YAML against the GitLab API)

You can now use the included utility diff-full-config to see the diff between two merged configurations (includes and templates inlined) in a given environment (environments correspond roughly to pipeline types). The basic invocation is:

gci-tezos diff-full-config COMMIT1 COMMIT2 ENVIRONMENT

So do e.g.

gci-tezos diff-full-config origin/master HEAD before_merging

with this MR checked out to see the differences between origin/master and the tip of this branch in the before_merging environment.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR