[go: up one dir, main page]

CI-in-OCaml: translate [master_branch]

Arvid Jakobssonrequested to merge
arvid@gitlab-ci.yml-in-ocaml--master_branch into master

What

Translates the master_branch pipeline to CI-in-OCaml

Why

See !11999 (merged) for rationale.

How

By generating each job individually, and then by putting the fully generated the pipeline in master_branch.yml. I terminate by removing external files that are no longer included from other pipelines and by removing unused templates.

Context

Builds on !11500 (merged)

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)
  4. !11461 (merged) (translate latest_release pipeline)
  5. !11500 (merged) (translate *release_tag(test) pipelines)
  6. !11501 (merged) (translate master_branch pipeline) <- You are here
  7. !11534 (closed) (translate schedule_extended_test pipeline)
  8. !11671 (closed) (translate before_merging pipeline)

Manually testing the MR

This MR rewrites the master_branch pipeline in OCaml-in-CI. You can check that this MR introduces no semantic changes to the configuration 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 $(git merge-base master HEAD) HEAD master_branch

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

You'll notice a small diff. These are:

  • Changing when: always to rules:when:always. These forms are equivalent and I use the former because it is a little bit more convenient.
  • There is only one cache for the job publish_kernel_sdk so there is no need to use the list form.

You can verify that, in fact, this MR introduces no changes to any other environment by changing master_branch to all-envs in the above command:

gci-tezos diff-full-config $(git merge-base master HEAD) HEAD all-envs

You should only see the diffs on master_branch.

Since I removed files and templates, you might worry that I removed something that is used somewhere. Such errors can be detected by linting. To do that, you have to setup an access token as describe above. Then run:

gci-tezos lint-all-environments

If you're of the paranoid inclination, then you can also spawn an artificial master_branch pipeline. This also requires a token as setup above. Then run:

gci-tezos run-pipeline --gl-project tezos/tezos --env master_branch

I've done so here: https://gitlab.com/tezos/tezos/-/pipelines/1197246144

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
Edited by Arvid Jakobsson

Merge request reports