Re: Enabling salsa-ci on all Debian Python Team repos
Hi Carsten, Hi List, Le Fri, Sep 23, 2022 at 07:01:05AM +0200, Carsten Schoenert a écrit : > heavily force pushing to not blow up the git tree with dozens of Fixup > commits! In the 'official' git tree this is a no go of course. Would doing the work in a git branch and 'git merge --squash' at the end be a solution to this problem ? I have the same issue when trying to use CI to run tests instead of running them locally, but using Mercurial, I just 'hg amend' them and I end up with a clean history. With Mercurial and its concept of obsolete commit combined with the evolve extension, a team can amend commits and share these amended commits without anyone losing work. I never found the equivalent in git where rewriting an history to clean it once the dust as settled breaks every repository that already pulled these commits. In other words, Mercurial allows you to work in a decentralized fashion both on your source and on the history of your source. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances
Re: Enabling salsa-ci on all Debian Python Team repos
Hi Carsten (2022.09.23_05:01:05_+) > sure, that's a killer argument that I can't really argue against. But that > is not the point for me. > > For all these checks we already have existing infrastructure, running the > same also by a pipeline job isn't helping at all if it's not clear how to > handle the fallout (we already mostly have seen in other places too!). Yeah, it's similar for me. I test build locally, my sbuild setup does most (but not all) of the same checks as gitlab CI. Then when I'm happy I push and upload. If there is any gitlab CI, it runs too late. And if it fails, I usually don't even bother to investigate, because I trust my local setup implicitly. Anything that's failing in gitlab CI is almost certain to be a failure specific to gitlab CI. I do see a value in having it enabled globally, for the team, though. 1. It can make the team packages friendlier to new contributor team members who don't have a setup like that. I would like to see our team act more like a team and have people contribute to packages that they don't regularly maintain. 2. Getting a test failure on a merge-request catches contributor mistakes early. I love having CI on incoming patches like that. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Enabling salsa-ci on all Debian Python Team repos
Hello Emanuele, Am 21.09.22 um 12:01 schrieb Emanuele Rocca: 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! sure, that's a killer argument that I can't really argue against. But that is not the point for me. For all these checks we already have existing infrastructure, running the same also by a pipeline job isn't helping at all if it's not clear how to handle the fallout (we already mostly have seen in other places too!). As Sandro and Arnaud have pointed out it's probably mostly a matter of the workflow for a package upload. And for me the CI pipeline stuff right now doesn't fit really into the package upload workflow that is typically used. Using the CI stuff in your own namespace is perfectly fine and I'm using this option from time to time. But I use there also the possibility to do heavily force pushing to not blow up the git tree with dozens of Fixup commits! In the 'official' git tree this is a no go of course. Nobody is perfect and even every Python package will have it's own small differences in between. As long as we don't have *one* Debian way to build packages and a helpful way to deal with breakage in any of the test runs it will always be a waste of time an energy to run for all packages a CI run at all times! If the decision is to do this step I will simply need to ignore any errors that are not RC. 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? I do all package built locally as a all/any build run. As written above and trying to say, I like atomic git commits that are doing things "correct" and by looking at the commit it's clear why this commit was done. I have to "fight" enough on my day job with my colleagues as they do git mostly using committing every forward and backward steps with no clean up locally finally before pushing their stuff and so I need to spend a lot of time to get the changes and their basically meaning. You would end up the same in the packages here as people would commit again and again to fix up the packages. I stand on my thinking, it's not helpful to enable a global CI for all packages. Doing this from case to case is absolutely fine to me. Arnaud Ferraris has written about the usage of a CI option in Debian Mobile etc. His writing is affirming me as I see and have the same experience within the PureOS ecosystem. People work there the same as I did describe, package are prepared in the local namespace and if the CI is running there successfully then a push to the team namespace is done. -- Regards Carsten
Re: Enabling salsa-ci on all Debian Python Team repos
> 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? sure its better, now let's assume something in those tests fails: how do you debug it and fix it? you still need to repeat it locally = you wasted time. In conclusion, you're no only proposing a technical change (add CI to all our packages), but also a workflow change (push to salsa before an upload). experience dictates that's never a good idea, and in such an heterogeneous team like ours, it's simply not gonna give the fruits you think it will. I still think it's a waste of time, and addition of emails that we're going to simply ignore (or not receive at all, if you're not subscribed to tracker.d.o, wihch is suspect is the vast majority of team members), but if the majority of the core contributors want it, sure go ahead -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Enabling salsa-ci on all Debian Python Team repos
Emanuele Rocca writes: > What's wrong with pushing your work before uploading to ftp-master > instead? :-) I am learning to do this with my packages. Because otherwise, when I push to get, I often find I forgot to do a pull beforehand, and there are changes in salsa that are not reflected in my upload I just did, and as I result I have a bit of a mess to try and resolve. But still, I need to remember to do it in this order. Normal solution would be to get the CI to upload the new changes automatically, but I imagine there are going to be problems here regarding control of the GPG key required to sign that changes file. -- Brian May https://linuxpenguins.xyz/brian/
Re: Enabling salsa-ci on all Debian Python Team repos
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.
Re: Enabling salsa-ci on all Debian Python Team repos
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
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
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
> 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". exactly this. 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. For future ones? maybe, but that's to be proven, and the burden of proof is on the proponent. Someone with upload rights still need to verify (and build!) a package locally, so what would be the advantage of this CI for our packages, given only a very very tiny number of MRs are submitted i could see the benefit for projects that receive external contributions and/or are released out-of-sync with such contributions (say dh-python) but for /packages/, as Carsten said, it's a waste of CPU time to enable CI, IMO -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Enabling salsa-ci on all Debian Python Team repos
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! 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. -- Regards Carsten
Re: Enabling salsa-ci on all Debian Python Team repos
Hi Sandro, On Tue, Sep 20, 2022 at 08:31:14AM -0400, Sandro Tosi wrote: > the way i worded my initial question was so that you could list the > reasons that make it so useful, in detail: so would you like to do? 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. 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. :-)
Re: Enabling salsa-ci on all Debian Python Team repos
On Tue, Sep 20, 2022 at 4:33 AM Emanuele Rocca wrote: > On 19/09 02:14, Sandro Tosi wrote: > > what would the team get out of doing this? > > The way I see it, CI on Salsa is so useful that it should be enabled by > default unless there are good reasons not to. the way i worded my initial question was so that you could list the reasons that make it so useful, in detail: so would you like to do? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Enabling salsa-ci on all Debian Python Team repos
Hi Sandro, On 19/09 02:14, Sandro Tosi wrote: > what would the team get out of doing this? The way I see it, CI on Salsa is so useful that it should be enabled by default unless there are good reasons not to. ciao, Emanuele
Re: Enabling salsa-ci on all Debian Python Team repos
> I was wondering if it would make sense to enable CI/CD on Salsa for all > projects owned by the Debian Python Team, or if there's any concern > about scaling issues in terms of pipeline workers (or anything else > really). what would the team get out of doing this? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Enabling salsa-ci on all Debian Python Team repos
On 2022-09-19 06 h 51, Emanuele Rocca wrote: Hello debian-salsa-ci and debian-python! I was wondering if it would make sense to enable CI/CD on Salsa for all projects owned by the Debian Python Team, or if there's any concern about scaling issues in terms of pipeline workers (or anything else really). For the past few days I've been enabling CI/CD on Salsa for various packages owned by the DPT. I've been doing this on a case-by-case basis: if the package I wanted to work on (for reasons unrelated to CI) did not have CI/CD yet, I'd add [1] as the pipeline configuration file and carry on with my work. Perhaps there's an opportunity to automate and getting wider CI usage. Thanks, Emanuele [1] recipes/debian.yml@salsa-ci-team/pipeline Hi, I was told "please don't" 3 years ago and although I've pushed a number of times (in private and in public), I have had no replies: https://salsa.debian.org/salsa/support/-/issues/170 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
