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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to