Skip to content

ci: test installation on last linux distro

Nic Volanschi requested to merge nic@test-last-linux-doc into master

Context

Closes #6763 (closed).

This MR adds a periodic test (in the scheduled pipeline) to check whether Octez can be compiled from sources on the latest Ubuntu distro, even if it's not an LTS.

Currently the latest distro is Mantic (23.10), while the latest LTS is Jammy (22.04).

Beware, there are several installation procedures for Octez, other the compiling from source, but adding tests for all of them is not as easily, or irrelevant, IMO:

  • static binaries should work without problem, so they are not currently tested on any distro
  • pre-built packages for Debian and Fedora are not provided for Mantic by Serokell on their PPA/Copr repo, but only for LTS distros
    • note that we could rather test the pre-built packages in our [Tezos package registry](https://gitlab.com/tezos/tezos/-/packages/), but they are not provided as a PPA/Copr repo compatible with apt/dnf.
    • therefore, testing these packages would be possible and meaningful, but this would require either:
      • a new install script under docs/introduction/, which should be updated at each release (since the package names change).
      • providing install scripts with each release in the Tezos package registry, along with the pre-build packages
      • presenting the pre-built packages as PPA/Copr repos
  • Opam installation tests are extremely long, so adding such a test on Mantic seems not enough cost-effective.

But feel free to promote one of the options above for testing Linux packages or suggest other relevant and cost-effective testing cases.

Manually testing the MR

Check that in the CI "test" stage there is a new job oc.compile_sources_mantic and it executes successfully.

You may also try the test locally:

docs/scripts/test_install_scripts.sh compile-sources-mantic

Note that some manual inputs may be required in this latter case.

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 Nic Volanschi

Merge request reports