Re: Enabling salsa-ci on all Debian Python Team repos

[Emanuele Rocca]

Hallo Carsten,

On 2022-09-20 05:35, Carsten Schoenert wrote:
> Am 20.09.22 um 16:13 schrieb Emanuele Rocca:
> > Salsa CI is useful because it automatically performs binary/source builds,
> > arm64 crossbuilds, and it runs various pretty important tests such as 
> > lintian,
> > piuparts, reproducible build testing, and more. It also runs autopkgtest in
> > LXC.
> 
> quite most of these steps I usually need to do locally before I do any
> upload of packages.

Well but that's the whole point of automated testing. There's no *need*
to do it locally if it's already done by Salsa for you. What is already
automated and working pretty well is:

- amd64 build
- i386 build
- source build
- autopkgtest
- blhc
- lintian
- piuparts
- reprotest
- arm64 crossbuild

That's a pretty time consuming list of things to go through for a human!

The only work left to be done on your machine is a binary build to see
if the packages look good, perhaps some specific manual testing [1],
source build and upload. Isn't that better?

[1] though that may be an opportunity for writing a new autopkgtest!

Re: Enabling salsa-ci on all Debian Python Team repos

[Emanuele Rocca]

Hi,

On 2022-09-20 03:09, Sandro Tosi wrote:
> the vast majority of the team members (based on the commits email i
> receive) are uploading the package to the archive at the same time as
> they are pushing a full set of changes to salsa (and sometimes only
> *after* the package has been ACCEPTED); in this case CI runs too late,
> and it has 0 benefit for that specific upload.

Very interesting, I was missing this piece of information. So first do
all the work locally, perform all the testing manually, upload the
package to ftp-master and *then* when you're finished push to Salsa?

What's wrong with pushing your work before uploading to ftp-master
instead? :-)

If you're worried about breaking things, that's what git revert and/or
branches are for. I can maybe imagine that one doesn't like frequent
merge requests and merge commits, you can skip that too: just use a
remote branch for testing and only push to master once happy.

My workflow is roughly:

- while not done:
  - few local commits, binary build, basic local testing
  - git push
  - see if the pipeline is green
- source build, sign, upload

To me this seems a better approach in terms of team collaboration too.
While you iterate on your work it's clear to other team members that
someone is on the package, which may help in terms of avoiding
duplicated efforts.

Re: Enabling salsa-ci on all Debian Python Team repos

[Samuel Thibault]

Hello,

Emanuele Rocca, le mer. 21 sept. 2022 12:01:21 +0200, a ecrit:
> The only work left to be done on your machine is a binary build to see
> if the packages look good, perhaps some specific manual testing [1],
> 
> [1] though that may be an opportunity for writing a new autopkgtest!

Yes, nowadays autopkgtest does more testing than what I was previously
doing :)

(and it prevents other packages from breaking mines).

Samuel

Re: Enabling salsa-ci on all Debian Python Team repos

[Arnaud Ferraris]

Hi,

Le 20/09/2022 à 17:35, Carsten Schoenert a écrit :

Hi,

Am 20.09.22 um 16:13 schrieb Emanuele Rocca:
Salsa CI is useful because it automatically performs binary/source 
builds,
arm64 crossbuilds, and it runs various pretty important tests such as 
lintian,
piuparts, reproducible build testing, and more. It also runs 
autopkgtest in

LXC.


quite most of these steps I usually need to do locally before I do any 
upload of packages. So I see no real gain to run any pipeline by 
default, for me this would be just burning energy in CPU cycles just for 
"because we can".


CI/CD makes sense for me within a greater view such as is a version 
upgrade of package A not break other stuff in other packages, like does 
working all packages that now need to use a new version of pytest or 
setuptools, django etc. But that's not ready within the current way the 
default CI pipeline is working (in my POV).


So no, for me it makes currently no sense to enable a CI thingy for ALL 
packages by default!


It all depends on your workflow indeed, and I assume nothing would 
prevent anyone from disabling CI on a per-repo basis (or, depending on 
the final consensus, enabling it on a per-repo basis as well).


Just to give some feedback on this, both the DebianOnMobile and Mobian 
team have CI enabled for all repos, along with 2 group runners for 
specific things (native arm64 builds and some non-packaging-related jobs 
needing kvm).


Over the past 2 years this has proven extremely useful for the following 
reasons:
- it suits our workflow (develop locally, test it builds, then push and 
let CI handle the rest)
- it doesn't require developers to manually run autopkgtest, lintian, 
piuparts or bhlc (which they could forget/not have the time to do), so 
all those tests are executed anyway, bringing immediate attention should 
any issue arise
- we also have the benefit or reprotests which would be heavier to do 
locally
- a significant portion of the team members have little experience with 
Debian packaging, so having all these checks automated allows them to 
focus on quality packaging rather than implementing a complete workflow 
including tests etc...


Opinions may differ of course, and both the aforementioned team are very 
small (both in terms of members and packages) compared to the Python 
team, but in our case we would definitely miss CI if it weren't there.


Cheers,
Arnaud



We have automatic Lintian checks, the buildds itself, and also the 
autopkgtest infrastructure, why double such things, that's waste of 
energy and resources! The packages are not getting better by running 
tests multiple times within the same environment.
And given my experience within other teams and groups, nobody really 
cares about packages that fail in some tests within a CI run. I strongly 
believe it wouldn't be better here.


Sure you can do all this manually on your own, but it's better to live 
in a
world where the machines work for us rather than the other way around. 
:-)


I still don't see why this is a benefit.
If you use an CI option within your own namespace is another thing, 
doing so make sense to me to prepare a new version for uploading.