team repo configuration on salsa

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

team repo configuration on salsa

Cédric Boutillier-6
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 deactivated job KGB notifications in IRC channel causing a lot of
  noise when ci is activated

(note that I didn't create the corresponding debian/salsa-ci.yml files
in the repos).

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.

Cheers,

Cédric

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: team repo configuration on salsa

Utkarsh Gupta
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: team repo configuration on salsa

Pirate Praveen-3
In reply to this post by Cédric Boutillier-6


On 2019, ഓഗസ്റ്റ് 12 3:18:32 PM IST, "Cédric Boutillier" <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: team repo configuration on salsa

Cédric Boutillier-6
Hi,

I managed to correctly shut down job notifications, and keep only success/failure pipeline notifications on all our projects (using a trick from the postgres team, abusing the irc channel option for the salsa tool to pass additional parameters to KGB).

Cheers

Cédric
Reply | Threaded
Open this post in threaded view
|

Re: team repo configuration on salsa

Utkarsh Gupta
In reply to this post by Cédric Boutillier-6
Hey,

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/

> 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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: team repo configuration on salsa

Georg Faerber-4
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

Reply | Threaded
Open this post in threaded view
|

Re: team repo configuration on salsa

Daniel Leidert-2
In reply to this post by Utkarsh Gupta
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: team repo configuration on salsa

Utkarsh Gupta
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



signature.asc (849 bytes) Download Attachment