CIAO: before_merging/scheduled, pt 5: test (scripts)

Stack

• !12695 (merged): test (scripts) <-- you are here
• !12696 (merged): test (tezt)
• !12697 (merged): test (kernels)
• !12698 (merged): docs
• !12699 (merged): coverage
• !12700 (merged): packaging (debian repository)
• !12701 (merged): concluding cleanup

What

Part of the CIAO translation of the test stage for the before_merging/scheduled pipelines. It includes: some documentation and refactorings; the generation of remaining oc.script:* jobs and install_octez.yml.

Why

How

There's nothing shocking in the first few commits. For the definition of oc.script:snapshot_alpha_and_link, I added a way of making pipeline-specific dependencies. Some types of dependency specifications are hard to translate automatically from one pipeline to another. For this job, we want to wait on the build jobs, but only if they are present, and only on before_merging pipelines. Setting this up required some convoluted code (suggestions welcome).

Remaining jobs are translated without surprises.

Manually testing the MR

This MR is best reviewed commit-per-commit for the OCaml part. Commits should have a message explaining any non-obvious changes.

For the generated YML, do review the result of these commands (see previous MRs like !11501 (merged) for setup instructions for gci-tezos):

$ gci-tezos diff-full-config master . master_branch,test_release_tag,release_tag,non_release_tag,non_release_tag_test,beta_release_tag
$ gci-tezos diff-full-config master . schedule_extended_tests
$ gci-tezos diff-full-config master . before_merging

Note, depending on the state on local checkout, you might get results of the above commands by replacing master with $(git merge-base origin/master HEAD), where origin might change depending on the name of your tezos git remote. this also requires that you've run a fetch on origin such that it does not lag behind the branch in this MR.

The first command shows no diff, meaning that those environments are unaffected.

The second two commands will show a diff. There might be some changes that might not be obivuos -- it is perhaps easiest to review the diff commit per commit:

$ gci-tezos diff-full-config COMMIT^ COMMIT all-envs

and read the associated commit message to understand the diff. You can read the output in a pseudo-git log like format with the following script diff-log.sh:

#!/bin/sh

set -eu

range="$1"
shift

git log --format=%H "${range}" | while read -r commit; do
  git log --color=always -n1 "$commit"
  echo
  gci-tezos diff-full-config "${commit}^" "${commit}" "$@" || true
  echo
done | less -R --quit-if-one-screen

and now do ./diff-log.sh master..HEAD all-envs (assuming that is the range you want to review). It should allow you to read, commit-per-commit, the message of the commit and the fully merged diff per 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