Re: Validating tarballs against git repositories

[Iustin Pop <iustin@debian.org>]

On 2024-03-31 00:58:49, Andrey Rakhmatullin wrote:
> On Sat, Mar 30, 2024 at 10:56:40AM +0100, Iustin Pop wrote:
> > > Now it is time to take a step forward:
> > > 
> > > 1. new upstream release;
> > > 2. the DD/DM merges the upstream release VCS into the Debian VCS;
> > > 3. the buildd is notified of the new release;
> > > 4. the buildd creates and uploads the non-reviewed-in-practice blobs "source
> > > deb" and "binary deb" to unstable.
> > > 
> > > This change would have three advantages:
> > 
> > I think everyone fully agrees this is a good thing, no need to list the
> > advantages.
> > 
> > The problem is that this requies functionality testing to be fully
> > automated via autopkgtest, and moved off the "update changelog, build
> > package, test locally, test some more, upload".
> Do you mean this theoretical workflow will not have a step of the
> maintainer actually looking at the package and running it locally, or
> running any building or linting locally before pushing the changes?
> Then yeah, looking at some questions in the past years I understand that
> some people are already doing that, powered by Salsa CI (I can think of
> several possible reasons for that workflow but it still frustrates me).

Not that it necessarily won't have that step, but how to integrate the
testing into the tag signing/pushing step.

I.e. before moving archive wide to "sign tag + push", there should be a
standard of how this is all tested for a package. Maybe there is and I'm
not aware, my Debian activities are very low key (but I try to keep up
with mailing lists).

> > Give me good Salsa support for autopkgtest + lintian + piuparts, and
> > easy support (so that I just have to toggle one checkbox), and I'm
> > happy. Or even better, integrate all that testing with Salsa (I don't
> > know if it has "CI tests must pass before merging"), and block tagging
> > on the tagged version having been successfully tested.
> AFAIK the currently suggested way of enabling that is putting
> "recipes/debian.yml@salsa-ci-team/pipeline" into "CI/CD configuration
> file" in the salsa settings (no idea where is the page that tells that or
> how to find it even knowing it exists).

Aha, see, this I didn't know. On my list to test once archive is
unblocked and I have time for packaging.

regards,
iustin