[go: up one dir, main page]

Release debian packages ( next -> current )

pietrorequested to merge
nomadic-labs/tezos:abate@deb-current-cleanup2 into master

What

This MR focuses on debian packaging.

This MR is part of a series of MRs that aim to upgrade the next ( rpm and deb ) packages ( now next ) and remove the "current" packages. This MR touch only the documentation and CI, we do not remove the code for the current packages and it is still used to test for upgrades.

The plan

  • !16645 (merged) ( release rpm packages ) .This MR add the next rpm packages in the release pipelines making available the rpm packages in the dnf repository.
  • !16646 (merged) ( cleanup rpm packages ) This MR removes the current packages from the release pipeline and scheduled pipelines.
  • !15854 (merged) ( doc for rpm packages ) This MR fix the documentation about packages reflecting the new release
  • !16678 (merged) publish dnf repository at packages.nomadic-labs.com
  • !16647 (closed) ( cleanup deb packages ) This MR removes the deb current packages from the release pipelines and rename current to old.

In particular this MR takes care of

  • remove current packages to release pipelines
  • move current to old
  • move next to "released"
  • fix installation and upgrade tests

Why

How

Manually testing the MR

Here are the important aspects to consider while testing this MR, with spelling fixed and text clarified:

  • Does it compile locally?
  • Can it be installed locally?
  • Can the octez-node and a baker be run locally using systemd?
  • Does the package correctly upgrade from an already installed package?
  • Does the package compile in a Docker container?
  • Do all CI checks pass?
  • Is the installation process user-friendly with clear questions and a good UX?
  • Can the package be easily migrated from a Serokell Debian package?
  • Does the MR introduce any regressions in lintian?

It's important to note that the CI cannot check all possible use cases, particularly the interactive installation process. Therefore, it's crucial for the reviewer to manually check in a Docker container or VM if the package can be installed interactively and configured as a working Octez service using systemd.

While the MR creator has already performed these manual steps, it's important for the reviewer to independently repeat these tests. For reference, reviewers should consult the following resources:

Local testing:

To test Debian packages locally, you need a Debian machine with the following packages installed:

  • dpkg-buildpackage
  • lintian
  • debconf-utils

Use the script scripts/packaging/build-deb-local.sh to build Debian packages locally. It accepts two arguments: binaries and zcash to compile all binary packages and all data packages, respectively. Use the --dev flag to run lintian.

While testing the packages locally you should also test for lintian and make sure we didn't introduce any regressions.

CI packages testing

To test packages produced in the CI, refer to the official documentation: Tezos CI Documentation

The CI creates an apt repository for each MR. Replace $CI_COMMIT_REF_NAME with the ref name related to this MR.

For distributions other than debian/bookworm, run a scheduled pipeline to generate packages for this MR using:

pipeline-profiler/run_pipeline_type.sh schedule_extended_test

Then, to test the packages related to this MR you can simply export the env variables as :

    export distribution=next/$CI_COMMIT_REF_NAME/debian
    export release=bookworm

and the follow all the steps in the detailed section dedicated to the installation of the debian packages: https://tezos.gitlab.io/introduction/services.html

We also have a dedicated page for the migration from the Serokell packages that should be considered : https://tezos.gitlab.io/introduction/serokell.html

Test debian packages in isolation

To test Debian packages in a clean environment using Docker, install Docker (Docker Installation Guide https://docs.docker.com/engine/install/#supported-platforms ) and use the following Dockerfile:

FROM debian:bookworm

ARG CI_COMMIT_REF_NAME

RUN apt-get update && apt-get install -y gpg curl

RUN curl https://tezos-linux-repo.storage.googleapis.com/next/debian/octez.asc | gpg --dearmor -o /etc/apt/keyrings/octez.gpg

RUN echo "deb [signed-by=/etc/apt/keyrings/octez.gpg] https://tezos-linux-repo.storage.googleapis.com/next/${CI_COMMIT_REF_NAME}/debian bookworm main" > /etc/apt/sources.list.d/octez.list

RUN apt-get update
RUN apt-get install -y octez-node

You can build the Dockerfile using the command

docker build -f Dockerfile.test --build-arg CI_COMMIT_REF_NAME=< the ref name of this MR> .

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 pietro

Merge request reports