On 19/04/2023 18:16, Sylvain Beucler wrote:
Hi,
On 17/04/2023 21:36, Sylvain Beucler wrote:
On 20/03/2023 09:40, Emilio Pozuelo Monfort wrote:
On 17/03/2023 19:39, Raphael Hertzog wrote:
On Thu, 16 Mar 2023, Emilio Pozuelo Monfort wrote:
The result is an improved pipeline with better support for both LTS and
ELTS. [1]
Great work Emilio!
It would be nice to have all this properly documented in
https://lts-team.pages.debian.net
Ack, I can add something to the testing section of the development page.
I'm wondering if this new CI environment is meant for all new repositories?
Currently LTS contributors are supposed to follow the following documentation:
https://lts-team.pages.debian.net/git-workflow-lts.html
which IIUC is also what was automated in:
https://gitlab.com/freexian/services/deblts-team/debian-lts/-/blob/master/bin/package-operations#L985
i.e. with a local debian/.gitlab-ci.yml relying on:
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
plus optionally disabling some tests.
Should we use that existing setup, or the new CI setup you presented, for new
LTS packages?
Additional elements:
- In the meantime, Emilio changed package-operations to reference the new recipe
for automated repository creation, thanks! :)
(The workflow doc still points to the old recipe).
- Emilio also answered this on IRC:
> yes, the new CI is meant for all lts repos.
> using the URL directly instead of a file works if the repo only contains *LTS
branches. for other use cases, pointing to the appropriate yml file would be best
I confirm that using the URL directly is currently annoying since even in
LTS-only repos, it triggers for 'upstream' and 'pristine-tar' branches (which
are not testable) :/
Right. Not sure if that can be avoided, but I'll take a look.
- Incidentally when attempting the new recipe with 'golang-1.11' it complains
about having 0 jobs to perform
https://salsa.debian.org/lts-team/packages/golang-1.11/-/pipelines/521038
That's because it's running on the git tag. lts.yml is using the branch name to
guess if it should include buster.yml, stretch.yml or jessie.yml (which set
RELEASE and other variables, e.g. jessie disables reprotest completely as
there's no reprotest in jessie). However the tag doesn't contain the release in
its name, unlike e.g. 'debian/buster'. Not sure why the pipeline got triggered
for the tag though, that didn't happen e.g. on the git repo:
https://salsa.debian.org/lts-team/packages/git/-/pipelines
Cheers,
Emilio