[go: up one dir, main page]

packages: release next rpm packages

pietrorequested to merge
nomadic-labs/tezos:abate@rpm-next-release into master

What

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 this MR I add the next rpm packages to the release pipelines making them available to the end user. The associated documentation is in this MR : !15854 (merged)

Why

This MR is part of the plant to replace the current rpm packages for 22.0 I do a cleanup here : !16646 (merged) where the current packages are going to be moved to "old", and the experimental packages to current.

How

This MR just adds a few pipelines to the release pipeline

Manually testing the MR

You can check the release pipeline here : https://gitlab.com/nomadic-labs/tezos/-/pipelines/1663380703

Check the rpm_repo_fedora and rpm_repo_rockylinux jobs

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 ?

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 a 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 in invited to independently repeat these tests. For reference, reviewers should consult the following resources:

Local testing:

To test RPM packages locally, you need a machine compatible with the rpm package manager with the following packages installed:

  • rpmbuild

Use the script scripts/packaging/build-rpm-local.sh to build RPM packages locally. It accepts two arguments: binaries and zcash to compile all binary packages and all data packages, respectively.

CI packages testing

The CI creates a dnf repository for each MR. These can be installed using dnf.

For RPM-based distributions other than rockylinux/9.3 (e.g. Fedora), run a scheduled pipeline to generate packages for this MR using:

./ci/run_pipeline/scheduled.sh

To install a rpm package, you need to configure the package manager to use the correct dnf repository. Replace $CI_COMMIT_REF_NAME with the ref name related to this MR.

dnf -y update
dnf -y install 'dnf-command(config-manager)'
dnf -y config-manager --add-repo "https://storage.googleapis.com/tezos-linux-repo/next/$CI_COMMIT_REF_NAME/rockylinux/dists/9.3/"

# only needed for rockylinux. not needed for fedora
dnf config-manager --set-enabled devel
rpm --import https://storage.googleapis.com/tezos-linux-repo/next/$CI_COMMIT_REF_NAME/rockylinux/octez.asc

Then we can use dnf to install the rpm packages and all their dependencies.

dnf -y update
dnf -y install octez-client octez-node octez-baker
rpm -v --info -q octez-client
rpm -v --verify octez-client

Test rpm packages in isolation

To test RPM 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 rockylinux:9.3

ARG CI_COMMIT_REF_NAME

SHELL ["/bin/bash", "-o", "pipefail", "-c"]

RUN dnf -y update
RUN dnf -y install 'dnf-command(config-manager)'
RUN dnf -y config-manager --add-repo "https://storage.googleapis.com/tezos-linux-repo/next/${CI_COMMIT_REF_NAME}/rockylinux/dists/9.3/"
# only needed for rockylinux. not needed for fedora
RUN dnf config-manager --set-enabled devel

RUN dnf -y update
RUN rpm --import https://storage.googleapis.com/tezos-linux-repo/next/${CI_COMMIT_REF_NAME}/rockylinux/octez.asc
RUN dnf -y install octez-client octez-node octez-baker
RUN rpm -v --info -q octez-client
RUN rpm -v --verify octez-client

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> .

Testing fedora packages.

On a merge pipeline we only generate (with a manual job) rockylinux packages. If you want to test fedora packages, you must run a scheduled pipeline for this branch using the script ./ci/run_pipeline/scheduled.sh

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