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. 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
