Re: team repo configuration on salsa
Hey, On 28/08/19 1:59 pm, Georg Faerber wrote: > On 19-08-28 13:26:40, Utkarsh Gupta wrote: >> The upstream code is mostly hosted on GitHub, but that's not the case >> always, no? > Yes. > >> I am not sure how to do this d/watch thingy because though the >> homepage mentioned is mostly the URL where the source code is hosted >> but sometimes it refers to the hosted page or whatever. >> I tried thinking of something but meh, left it on/for you :P > :) > > What about "best effort"? > > gem2deb could initially fetch the gem, parse it and search for a link to > GitHub "which looks like the repo". If found, use it in d/watch, > otherwise rely on rubygems. Sounds good to me. We can always experiment with things, so I'd say do it and lets see how it goes :D Personally, I think it'd be great. Best, Utkarsh signature.asc Description: OpenPGP digital signature
Re: team repo configuration on salsa
On 19-08-28 13:26:40, Utkarsh Gupta wrote: > The upstream code is mostly hosted on GitHub, but that's not the case > always, no? Yes. > I am not sure how to do this d/watch thingy because though the > homepage mentioned is mostly the URL where the source code is hosted > but sometimes it refers to the hosted page or whatever. > I tried thinking of something but meh, left it on/for you :P :) What about "best effort"? gem2deb could initially fetch the gem, parse it and search for a link to GitHub "which looks like the repo". If found, use it in d/watch, otherwise rely on rubygems. Cheers, Georg
Re: team repo configuration on salsa
Hi, On 19-08-12 11:48:32, Cédric Boutillier wrote: > This is a list of packages I noticed already used ci, but not with > debian/salsa-ci.conf. > the ci config file is still pointing to the original file. > > [...] > ruby-gpgme > ruby-mail-gpg > schleuder > schleuder-gitlab-ticketing I've fixed these. Cheers, Georg
Re: team repo configuration on salsa
Hey, On 28/08/19 12:26 pm, Georg Faerber wrote: > On 19-08-28 10:13:53, Utkarsh Gupta wrote: >> Perfecto. >> I just did add a metadata file to include d/upstream/metadata (as we >> discussed in the BoF); rest in on you :D > :) > >> Also, if possible, I'd love to see gem2deb using the correct upstream >> tarballs in d/watch *somehow* instead of what it fetches from rubygems. >> Might take some tweaking but would be worth it :D > I guess we could prefer GitHub if there is consensus for this, which > might also help with including the testsuites, which sometimes are not > included in the gem. Probably, it's possible to find the correct url via > parsing the gem. If nothing is found, the code could fallback to > rubygems. The upstream code is mostly hosted on GitHub, but that's not the case always, no? I am not sure how to do this d/watch thingy because though the homepage mentioned is mostly the URL where the source code is hosted but sometimes it refers to the hosted page or whatever. I tried thinking of something but meh, left it on/for you :P Best, Utkarsh signature.asc Description: OpenPGP digital signature
Re: team repo configuration on salsa
On 19-08-28 10:13:53, Utkarsh Gupta wrote: > Perfecto. > I just did add a metadata file to include d/upstream/metadata (as we > discussed in the BoF); rest in on you :D :) > Also, if possible, I'd love to see gem2deb using the correct upstream > tarballs in d/watch *somehow* instead of what it fetches from rubygems. > Might take some tweaking but would be worth it :D I guess we could prefer GitHub if there is consensus for this, which might also help with including the testsuites, which sometimes are not included in the gem. Probably, it's possible to find the correct url via parsing the gem. If nothing is found, the code could fallback to rubygems. Cheers, Georg
Re: team repo configuration on salsa
Hey Georg, On 14/08/19 3:43 pm, Georg Faerber wrote: > Hi Utkarsh, all, > > On 19-08-14 03:44:02, Utkarsh Gupta wrote: >> But FWIW, we have CI enabled for every package under the Ruby team now. > That's really great, thanks to everyone involved! > >> Over the next few days, I'll integrate a couple of things in gem2deb >> as well (if no one does by then). > I still stand by the words I said during the BoF regarding this, but > just returned from traveling, I could tackle this in September. If you > want to do it earlier, please go ahead. Perfecto. I just did add a metadata file to include d/upstream/metadata (as we discussed in the BoF); rest in on you :D Also, if possible, I'd love to see gem2deb using the correct upstream tarballs in d/watch *somehow* instead of what it fetches from rubygems. Might take some tweaking but would be worth it :D Best, Utkarsh signature.asc Description: OpenPGP digital signature
Re: team repo configuration on salsa
Hey, On 14/08/19 5:15 pm, Daniel Leidert wrote: > Am Mittwoch, den 14.08.2019, 03:44 +0530 schrieb Utkarsh Gupta: >> On 12/08/19 3:18 pm, Cédric Boutillier wrote: >>> >>> >>> (note that I didn't create the corresponding debian/salsa-ci.yml files >>> in the repos). >> The whole world knows by now, but still.. >> I have initialized debian/salsa-ci.yml in every repository. >> Though it did break Salsa CI, but at least it is working for all the >> repositories now (except the ones listed by Cedric below). >> Had a word with Bastian and it now seems that everything is back up \o/ > It is too late now, but still: debian/salsa-ci.yml ist not necessary for > packaging. It should therefor not be part of the Debian package. Thus it > should > be excluded from an export via .gitattributes and you definitely shouldn't > have > altered debian/changelog for it! The latter is really annyoing, especially > several of my packages are currently waiting in NEW. A simple commit message > would have sufficed. The first issue now creates another one. Mass-adding > debian/.gitattributes. If you do so, please add '[ci skip]' to the commit > message so it won't trigger 1300 new pipelines. > > https://docs.gitlab.com/ee/ci/yaml/README.html#skipping-jobs > > If you add debian/.gitattributes, please add it with this content: > > > .gitattributes export-ignore > gbp.conf export-ignore > salsa-ci.yml > > and don't alter debian/changelog. Make sense to me. Let me know if anyone has a problem with it? If not, I shall do this by the next weekend. > PS: I was thinking about adding a team-specific custom version of pipeline- > jobs.yml to the ruby teams meta repository enabling only the really required > jobs build, linitan and autopkgtest...? blhc IMHO is not useful for most ruby > packages. Complex packages could still use the version from the Salsa CI team. > Also you should be aware, that both pushing commits _and_ tags currently > triggers running all the jobs. So by pushing your last changes inclusing the > tag, you'l trigfger two pipelines. So a custom version could make use of > except/only rules to keep the payload to a minimum. That's just a quick > thought. Sounds fine to me. Best, Utkarsh signature.asc Description: OpenPGP digital signature
Re: team repo configuration on salsa
Am Mittwoch, den 14.08.2019, 03:44 +0530 schrieb Utkarsh Gupta: > On 12/08/19 3:18 pm, Cédric Boutillier wrote: > > > > > > (note that I didn't create the corresponding debian/salsa-ci.yml files > > in the repos). > > The whole world knows by now, but still.. > I have initialized debian/salsa-ci.yml in every repository. > Though it did break Salsa CI, but at least it is working for all the > repositories now (except the ones listed by Cedric below). > Had a word with Bastian and it now seems that everything is back up \o/ It is too late now, but still: debian/salsa-ci.yml ist not necessary for packaging. It should therefor not be part of the Debian package. Thus it should be excluded from an export via .gitattributes and you definitely shouldn't have altered debian/changelog for it! The latter is really annyoing, especially several of my packages are currently waiting in NEW. A simple commit message would have sufficed. The first issue now creates another one. Mass-adding debian/.gitattributes. If you do so, please add '[ci skip]' to the commit message so it won't trigger 1300 new pipelines. https://docs.gitlab.com/ee/ci/yaml/README.html#skipping-jobs If you add debian/.gitattributes, please add it with this content: .gitattributes export-ignore gbp.conf export-ignore salsa-ci.yml and don't alter debian/changelog. PS: I was thinking about adding a team-specific custom version of pipeline- jobs.yml to the ruby teams meta repository enabling only the really required jobs build, linitan and autopkgtest...? blhc IMHO is not useful for most ruby packages. Complex packages could still use the version from the Salsa CI team. Also you should be aware, that both pushing commits _and_ tags currently triggers running all the jobs. So by pushing your last changes inclusing the tag, you'l trigfger two pipelines. So a custom version could make use of except/only rules to keep the payload to a minimum. That's just a quick thought. Regards, Daniel signature.asc Description: This is a digitally signed message part
Re: team repo configuration on salsa
Hi Utkarsh, all, On 19-08-14 03:44:02, Utkarsh Gupta wrote: > But FWIW, we have CI enabled for every package under the Ruby team now. That's really great, thanks to everyone involved! > Over the next few days, I'll integrate a couple of things in gem2deb > as well (if no one does by then). I still stand by the words I said during the BoF regarding this, but just returned from traveling, I could tackle this in September. If you want to do it earlier, please go ahead. Cheers, Georg
Re: team repo configuration on salsa
Hey, On 12/08/19 3:18 pm, Cédric Boutillier wrote: > > > (note that I didn't create the corresponding debian/salsa-ci.yml files > in the repos). The whole world knows by now, but still.. I have initialized debian/salsa-ci.yml in every repository. Though it did break Salsa CI, but at least it is working for all the repositories now (except the ones listed by Cedric below). Had a word with Bastian and it now seems that everything is back up \o/ > This is a list of packages I noticed already used ci, but not with > debian/salsa-ci.conf. > the ci config file is still pointing to the original file. > > chake > gitlab > gitlab-shell > ruby-gitlab-sidekiq-fetcher > ruby-gpgme > ruby-mail-gpg > schleuder > schleuder-gitlab-ticketing > > If your package was in this situation and is not in the list, I > apologize. Please check and tell me, and I'll fix it, or it can also be > time to switch to salsa-ci... > > If we consider that all the pipeline notifications are already too > noisy, we can filter them by adding > > ;pipeline_only_status=failed;pipeline_only_status=success > > at the end of the KGB webhook url. Also, apologies for thousands of notifications on the channel. I thought we won't get CI notifications, but oh well. And in the script that I wrote, I did add a flag to disable mass commit notifications, but after Antonio pinged about it, I checked that it only got disabled for me, not for everyone :/ But FWIW, we have CI enabled for every package under the Ruby team now. Over the next few days, I'll integrate a couple of things in gem2deb as well (if no one does by then). Best, Utkarsh signature.asc Description: OpenPGP digital signature
Re: team repo configuration on salsa
On 2019, ഓഗസ്റ്റ് 12 3:18:32 PM IST, "Cédric Boutillier" wrote: >If we consider that all the pipeline notifications are already too >noisy, we can filter them by adding > >;pipeline_only_status=failed;pipeline_only_status=success > >at the end of the KGB webhook url. Yes, we should see only success or failure (or even just failure if we assume success by default). -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: team repo configuration on salsa
Hey, On 12/08/19 3:18 pm, Cédric Boutillier wrote: > Dear team, > > I went ahead and applied some (hopefully unnoticed) changes to the > configuration of our repositories: > - I set debian/salsa-ci.yml as the path for ci on salsa I had done this for 1411 projects already, much earlier today :D I was about to mail regarding the same. I am also preparing to add debian/salsa-ci.yml file for all the projects as well. > - I deactivated job KGB notifications in IRC channel causing a lot of > noise when ci is activated Perfecto, thanks! > (note that I didn't create the corresponding debian/salsa-ci.yml files > in the repos). I am doing it; don't worry about it. > I created a config file "salsa-ruby-team-policy.conf" for the 'salsa' > tool in devscripts, which reflects the options I set, and ran > > salsa --conffile +salsa-ruby-team-policy.conf update_repo --all > --no-fail > > This is a list of packages I noticed already used ci, but not with > debian/salsa-ci.conf. > the ci config file is still pointing to the original file. > > chake > gitlab > gitlab-shell > ruby-gitlab-sidekiq-fetcher > ruby-gpgme > ruby-mail-gpg > schleuder > schleuder-gitlab-ticketing > > If your package was in this situation and is not in the list, I > apologize. Please check and tell me, and I'll fix it, or it can also be > time to switch to salsa-ci... > > If we consider that all the pipeline notifications are already too > noisy, we can filter them by adding > > ;pipeline_only_status=failed;pipeline_only_status=success > > at the end of the KGB webhook url. Sweet. We should also have all this integrated with gem2deb as well :) Best, Utkarsh signature.asc Description: OpenPGP digital signature
