Signed-off-by: Apertis CI <devel@lists.apertis.org>

Signed-off-by: Apertis CI <devel@lists.apertis.org>

Signed-off-by: Ritesh Raj Sarraf <rrs@debian.org>

Include Apertis toolchain in the list of builds. In this way we build daily
images and toolchains as it would be expected using the same identifier to
correlate them.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>

Signed-off-by: Ritesh Raj Sarraf <rrs@debian.org>

Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>

Signed-off-by: Ritesh Raj Sarraf <rrs@debian.org>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Now that v2022 has moved to Bullseye running on the ancient 3.14 kernel
used by the internal image is much more challenging.

The modern Bullseye userspace may fail due to missing syscalls, lack of
features or bugs in seven-years-old kernels.

The internal images are now no longer representative of the usage of
Apertis in that contenxt and alternative strategies that do not involve
the custom images would be much more effective in actually producing
value, so let's drop them from v2022.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

After the GitLab "Unauthenticated CI lint API may lead to information
disclosure and SSRF" fix shipped with version 13.8.4 the `ci/lint`
endpoints requires authentication but:

1. `$CI_JOB_TOKEN` is not enough
2. `$TEST_GITLAB_AUTH_TOKEN` is not enough either, some extra
   permissions are required

Given that the YAML will get executed in the same pipeline, let's
just drop the lint CI job rather than granting more permissions
than necessary.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

When releasing having different build ids for images/internal images/lxc
and so on make me waste time collecting stuff from different places, as
they often annoyingly differ by a minute or so.

It is also problematic on the LAVA reports app for the same reason.

To address that, this repository contains an orchestrator pipeline
that computes a build id and then triggers a few child pipelines that
use it.

The idea is to set a centralized schedule on this pipeline to replace
the schedules set on each project.

In the future this pipeline may be also a good place to stick a manual
job to turn a build into a release or release candidate, automating a
step which now involves manually ssh'ing to aura and calling a script.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>