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: >>> <snip> >>> >>> (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
Attachment:
signature.asc
Description: OpenPGP digital signature