Fwd: CPE Weekly Update: 2019-10-25

[Justin W. Flory]

Hi Badgers!

I saw this thread on the Infrastructure mailing list and I was confused. 
Does Tahrir/Badges still need a lead maintainer? I was under the 
impression Xavier volunteered. I wanted to make sure everyone is on the 
same page (see the excerpt below).


Does anyone know anything more? Is Badges at risk of being dropped past 
2020?




 Forwarded Message 
Subject:CPE Weekly Update: 2019-10-25
Date:   Fri, 25 Oct 2019 23:50:57 +0100
From:   Aoife Moloney 
Reply-To:   Fedora Infrastructure
To: infrastructure@lists.fedoraproject.org



Good Morning/Afternoon/Evening Everyone,

Welcome to week four of the CPE Weekly Updates!


/Background:The Community Platform Engineering group is the Red Hat team 
combining IT and release engineering from Fedora and CentOS. Our goal is 
to keep core servers and services running and maintained, build 
releases, and other strategic tasks that need more dedicated time than 
volunteers can give./


/
/

/For better communication, we will be giving weekly reports to the 
CentOS and Fedora communities about the general tasks and work being done. /



*_Maintainers Needed:_*
*_
_*
*- Tahrir: *If you would like to volunteer to maintain this app, please 
let us know by 2019-12-31!


*- Tahrir-api: *If you would like to volunteer to maintain this app, 
please let us know by 2019-12-31!
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

CPE Weekly Update: 2019-10-25

[Aoife Moloney]

Good Morning/Afternoon/Evening Everyone,

Welcome to week four of the CPE Weekly Updates!


*Background: The Community Platform Engineering group is the Red Hat team
combining IT and release engineering from Fedora and CentOS. Our goal is to
keep core servers and services running and maintained, build releases, and
other strategic tasks that need more dedicated time than volunteers can
give.*


*For better communication, we will be giving weekly reports to the CentOS
and Fedora communities about the general tasks and work being done.  *

































































*FedoraRawhide Gating:
New Bodhi 5.0 release is
now in staging- Bodhi staging container being moved from rpms to source to
allow for faster releaseStaging- Openshift issue blocking builds now
resolved, can be viewed here
->https://pagure.io/fedora-infrastructure/issue/8300
- Both Koji &
fedpckg/rpckg all working well- Looking into a way to trigger bodhi updates
rather than builds in the CI pipelineTracked here
-> https://pagure.io/fedora-ci/general/issue/70
Fedora Messaging:-
Ci-resultsdb-listener -> 1.0 release is out and running in staging (w/
support for fedora-messaging as well as the new message format)- Results
with the new format not fully showing on bodhi in staging yet so the team
is investigating!- Bugzilla2fedmsg was down this week, the team are working
to get it back online, if not already done so at the time of this email :)-
el8 is installed on aarch64/emag- Documentation created on how packagers
can use bodhi to manage Rawhide, including sidetags can be viewed here ->
https://github.com/fedora-infra/bodhi/issues/2322
- Documentation reviewed
and updates made here
->https://github.com/CentOS/docs-installation-guide/pull/9
- Changelog entry
to update notes for automatic updates is added here ->
https://github.com/fedora-infra/bodhi/pull/3548

repoSpanner:
- Performance prototype is now
PR: https://github.com/repoSpanner/repoSpanner/pull/98
- Performance now
boosted by 122%!!- Now looking towards profiling on production-like
hardware - stay tuned!CentOSMirrors- Switched
https://mirror-status.centos.org  to
centos 7 node (ansible managed) CentOS CI- Investigating an issue with
provisioning CentOS 6 in duffyw -
https://lists.centos.org/pipermail/ci-users/2019-October/000971.html
Migrations:-
phpbb version is also updgraded on www.centos.org/forums
 and fr.centos.org/forums
 - blog.centos.org 
is now moved to a new host/ansible roleCommunity Handover Applications:-
Elections: Still blocked - please help!PostgreSQL database is missing in
application cataloguehttps://pagure.io/fedora-infrastructure/issue/8253
- Fedocal: Maintainer
found and the team are working through the handover- Nuancier: New
maintainer is currently working on OIDC authentication so keep an eye out
for an update next week!- Pastebin: Fpaste client has been updated and we
are now working on redirecting fpaste.org  and
paste.fpo to the centos pastebinMaintainers Needed:- Tahrir: If you would
like to volunteer to maintain this app, please let us know by 2019-12-31!-
Tahrir-api: If you would like to volunteer to maintain this app, please let
us know by 2019-12-31!Retiring Applications:- Kitchen: Retiring on
2019-10-31- Keys: Retiring on 2019-10-31Comments? Suggestions? Feedback?
Let Us Know!And have a great weekend!Kindest regards,Aoife*--

Aoife Moloney

Feature Driver

Community Platform Engineering Team

Red Hat EMEA 

Communications House

Cork Road

Waterford



-- 

Aoife Moloney

Feature Driver

Community Platform Engineering Team

Red Hat EMEA 

Communications House

Cork Road

Waterford

___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Clement Verna]

On Fri, Oct 25, 2019, 21:42 Randy Barlow 
wrote:

> On Fri, 2019-10-25 at 14:53 -0400, Neal Gompa wrote:
> > It's not a bad feature to have in fedpkg, but it fundamentally does
> > not help *other people* discover what we have in the distribution.
>
> Yeah I've discussed this a bit with some people, and I agree. Fedora
> *users* might use the packages app to find out the same info that
> packagers want to find out.
>
> However, I think that even though users and packagers are coming to
> this app for the same purpose, only one of those purposes maps to the
> CPE team's mission statement: the packager's. If you are a packager,
> you *need* to know what versions are where at a glance, especially when
> dealing with something high priority like a CVE.
>
> That's not to say that the end-user story isn't a valuable use case,
> but our team is overburdened and we need to drop most of what we do
> right now, and we have to be specific about what our purpose is. This
> means dropping some valuable use cases.
>

https://pkgs.org/ might be a good replacement for that. Does anybody have
used or is using this website ? Any feedback on it ?


> Of course, this is also my own opinion, and I welcome disagreement.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Randy Barlow]

On Fri, 2019-10-25 at 15:50 -0400, Neal Gompa wrote:
> a lot of Fedora-specific information isn't
> present.

Though true for the entire packages app, I think this site does do the
one use case I described at a quick glance.


signature.asc
Description: This is a digitally signed message part
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Randy Barlow]

On Fri, 2019-10-25 at 14:53 -0400, Neal Gompa wrote:
> It's not a bad feature to have in fedpkg, but it fundamentally does
> not help *other people* discover what we have in the distribution. 

Yeah I've discussed this a bit with some people, and I agree. Fedora
*users* might use the packages app to find out the same info that
packagers want to find out.

However, I think that even though users and packagers are coming to
this app for the same purpose, only one of those purposes maps to the
CPE team's mission statement: the packager's. If you are a packager,
you *need* to know what versions are where at a glance, especially when
dealing with something high priority like a CVE.

That's not to say that the end-user story isn't a valuable use case,
but our team is overburdened and we need to drop most of what we do
right now, and we have to be specific about what our purpose is. This
means dropping some valuable use cases.

Of course, this is also my own opinion, and I welcome disagreement.


signature.asc
Description: This is a digitally signed message part
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Neal Gompa]

On Fri, Oct 25, 2019 at 3:48 PM Clement Verna  wrote:
>
>
>
> On Fri, Oct 25, 2019, 21:42 Randy Barlow  wrote:
>>
>> On Fri, 2019-10-25 at 14:53 -0400, Neal Gompa wrote:
>> > It's not a bad feature to have in fedpkg, but it fundamentally does
>> > not help *other people* discover what we have in the distribution.
>>
>> Yeah I've discussed this a bit with some people, and I agree. Fedora
>> *users* might use the packages app to find out the same info that
>> packagers want to find out.
>>
>> However, I think that even though users and packagers are coming to
>> this app for the same purpose, only one of those purposes maps to the
>> CPE team's mission statement: the packager's. If you are a packager,
>> you *need* to know what versions are where at a glance, especially when
>> dealing with something high priority like a CVE.
>>
>> That's not to say that the end-user story isn't a valuable use case,
>> but our team is overburdened and we need to drop most of what we do
>> right now, and we have to be specific about what our purpose is. This
>> means dropping some valuable use cases.
>
>
> https://pkgs.org/ might be a good replacement for that. Does anybody have 
> used or is using this website ? Any feedback on it ?
>

Some of the searching is a little awkward. It does let you see stuff
across distributions, but a lot of Fedora-specific information isn't
present.

Unfortunately, improving pkgs.org is impossible as the author is hard
to get ahold of and the software is not FOSS.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Randy Barlow]

On Fri, 2019-10-25 at 21:00 +0200, Mikolaj Izdebski wrote:
> I am planning to deploy Package Version Matrix in communishift [1].
> Example how it can look like: [2]
> 
> [1] https://pagure.io/fedora-infrastructure/issue/8314
> [2] https://koji.kjnet.xyz/kojifiles/versions/

Oh that could be a good replacement. Does it support searching, or
displaying a particular package rather than the full set (since there
are a lot of packages in all of Fedora)? If not, it's probably not hard
to add.


signature.asc
Description: This is a digitally signed message part
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Randy Barlow]

On Fri, 2019-10-25 at 21:47 +0200, Clement Verna wrote:
> https://pkgs.org/ might be a good replacement for that. Does anybody
> have used or is using this website ? Any feedback on it ?

I haven't seen this before, but if it does a good job staying up to
date then it seems like a good replacement to me, and someone else
already did it and even hosts it. Nice.


signature.asc
Description: This is a digitally signed message part
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Mikolaj Izdebski]

On Fri, Oct 25, 2019 at 8:43 PM Randy Barlow
 wrote:
> OK. Given our extreme time constraints, I think it is likely that we
> will have to retire the Packages app.
>
> However, there is one feature in it that I personally believe does map
> to the CPE team's mission statement: the table of which versions of a
> package are in which versions of Fedora/EPEL.

I am planning to deploy Package Version Matrix in communishift [1].
Example how it can look like: [2]

[1] https://pagure.io/fedora-infrastructure/issue/8314
[2] https://koji.kjnet.xyz/kojifiles/versions/

--
Mikolaj Izdebski
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Neal Gompa]

On Fri, Oct 25, 2019 at 2:43 PM Randy Barlow
 wrote:
>
> On Thu, 2019-10-24 at 20:12 +0200, Clement Verna wrote:
> > The packages app (https://apps.fedoraproject.org/packages/) was
> > originally running on RHEL6, I tried to move it to RHEL 7 but they
> > were some dependencies missing there so we decided to move it to
> > Fedora. I don't remember which dependencies were missing tho. One of
> > the pain point is that the frontend is rendered using moksha/tosca
> > widgets (http://toscawidgets.org/) and this is pretty much a dead
> > upstream project. Removing these dependencies is not going to be
> > trivial.
>
> OK. Given our extreme time constraints, I think it is likely that we
> will have to retire the Packages app.
>
> However, there is one feature in it that I personally believe does map
> to the CPE team's mission statement: the table of which versions of a
> package are in which versions of Fedora/EPEL.
>
> I think we should do *something* to continue to provide that particular
> feature to packagers. I have a proposal:
>
> What if we make a fedpkg subcommand that prints that table? I think it
> could get all the needed data by querying Koji.
>
> I suggest this instead of a webapp or service, because webapps and
> services increase the burden on the CPE team, and also because creating
> an entire application just to print a table is a lot of boilerplate.
>
> Adding it to fedpkg feels clean to me, because it seems like a sensible
> place for such a feature to exist, and because it *should* be simple
> and easy. Simple is good!
>
> I may be able to find the time to make this happen before April too.
>
> Thoughts?

It's not a bad feature to have in fedpkg, but it fundamentally does
not help *other people* discover what we have in the distribution. If
anything, the biggest problem with CLI tools over web apps is that
there's no intuitive way to discover anything. In my view, it does not
replace the purpose of the packages web app.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Randy Barlow]

On Thu, 2019-10-24 at 20:12 +0200, Clement Verna wrote:
> The packages app (https://apps.fedoraproject.org/packages/) was
> originally running on RHEL6, I tried to move it to RHEL 7 but they
> were some dependencies missing there so we decided to move it to
> Fedora. I don't remember which dependencies were missing tho. One of
> the pain point is that the frontend is rendered using moksha/tosca
> widgets (http://toscawidgets.org/) and this is pretty much a dead
> upstream project. Removing these dependencies is not going to be
> trivial.

OK. Given our extreme time constraints, I think it is likely that we
will have to retire the Packages app.

However, there is one feature in it that I personally believe does map
to the CPE team's mission statement: the table of which versions of a
package are in which versions of Fedora/EPEL.

I think we should do *something* to continue to provide that particular
feature to packagers. I have a proposal:

What if we make a fedpkg subcommand that prints that table? I think it
could get all the needed data by querying Koji.

I suggest this instead of a webapp or service, because webapps and
services increase the burden on the CPE team, and also because creating
an entire application just to print a table is a lot of boilerplate.

Adding it to fedpkg feels clean to me, because it seems like a sensible
place for such a feature to exist, and because it *should* be simple
and easy. Simple is good!

I may be able to find the time to make this happen before April too.

Thoughts?


signature.asc
Description: This is a digitally signed message part
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: ansible-report git hook design

[Randy Barlow]

On Fri, 2019-10-25 at 19:04 +0200, Clement Verna wrote:
> I think the main reason why we don't already have it on Pagure is
> that we don't want to be dependent of our own infrastructure to host
> this repo. It currently lives on the batcave01 host which is the box
> we use to deploy our infrastructure. So to me if we are going to host
> this repository on a git forge I think using an external service
> would make sense.

+1

> Of course we would then be dependent on a third party

Well, since git itself is a distributed scm, we aren't really
dependent. I bet there are many many copies of the Ansible repo on all
of our laptops (I have it on my laptop and on a local repospanner forge
in my house right now!). So even if we had it on Git* and that thing
went down, we still have like a hundred other copies of it.

> I think that the % of availability of GitHub or GitLab is much higher
> than ours, they have dedicated teams working on making sure their
> service is available when we struggle to keep all our infra running.
> Also their main business and expertise is to run a git forge service,
> they have the infrastructure and the hardware for that, while our
> main business is to build and release a Linux distribution (A really
> good one :-)

+1

> After I am not really interested in a long debate in regards of where
> that repo should be hosted, to me what matters is that we should have
> the Fedora Community in only one place be it GitLab like the Gnome
> community or GitHub where we already have fedora-infra, fedora-cloud, 
> fedora CoreOS.

Yeah GitHub and GitLab are both great.


signature.asc
Description: This is a digitally signed message part
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: ansible-report git hook design

[Clement Verna]

On Fri, 25 Oct 2019 at 16:47, Brian (bex) Exelbierd 
wrote:

>
>
> On Fri, Oct 25, 2019 at 3:28 PM Randy Barlow 
> wrote:
>
>> On Fri, 2019-10-25 at 15:03 +0200, Clement Verna wrote:
>> > There are basically 2 possibility :
>>
>> There are other possibilities too, such as putting the repo on
>> gitlab.com and using their CI on pull requests
>
>
> Can’t we do this on Pagure with CentOS CI?
>

I think the main reason why we don't already have it on Pagure is that we
don't want to be dependent of our own infrastructure to host this repo. It
currently lives on the batcave01 host which is the box we use to deploy our
infrastructure. So to me if we are going to host this repository on a git
forge I think using an external service would make sense. Of course we
would then be dependent on a third party but I think that the % of
availability of GitHub or GitLab is much higher than ours, they have
dedicated teams working on making sure their service is available when we
struggle to keep all our infra running. Also their main business and
expertise is to run a git forge service, they have the infrastructure and
the hardware for that, while our main business is to build and release a
Linux distribution (A really good one :-)

After I am not really interested in a long debate in regards of where that
repo should be hosted, to me what matters is that we should have the Fedora
Community in only one place be it GitLab like the Gnome community or GitHub
where we already have fedora-infra, fedora-cloud, fedora CoreOS.

Just my 2 cents :-)


>
> Thank you.
>
> regards,
>
> bex
>
>
> .
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to
>> infrastructure-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>>
> --
> Brian "bex" Exelbierd (he/him/his)
> Fedora Community Action & Impact Coordinator
> @bexelbie | http://www.winglemeyer.org
> bexel...@redhat.com | b...@pobox.com
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: ansible-report git hook design

[Brian (bex) Exelbierd]

On Fri, Oct 25, 2019 at 3:28 PM Randy Barlow 
wrote:

> On Fri, 2019-10-25 at 15:03 +0200, Clement Verna wrote:
> > There are basically 2 possibility :
>
> There are other possibilities too, such as putting the repo on
> gitlab.com and using their CI on pull requests


Can’t we do this on Pagure with CentOS CI?

Thank you.

regards,

bex


.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.com
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: ansible-report git hook design

[Julen Landa Alustiza]

For option 2, it could feasible to cutdown the cloning time from git push . the 
process will continue to slowdown the push, but not so much. It's just theory, 
but it might work:

1. We keep an updated master working copy somewhere else: ci working copy
2. On pre-receive hook, we create a branch on ci working copy, apply the 
commited patches, run ansible-report . if 
ansible-report returns 0, we move master to the same ref where the testing 
branch is, otherwise we checkout master and delete the testing branch

That will reduce the testing time since we will not clone the repo on every 
commit.

Anyhow, I feel that we are planning to emulate a CI system that runs tests on a 
PR and automerge them on success with custom bare git hooks, and this will be a 
long-term headache to maintain.

So, is there any benefit on doing this instead of planning a PR+CI+automerge on 
success with existing tools?

Regards and happy friday for all,

On October 25, 2019 3:03:36 PM GMT+02:00, Clement Verna 
 wrote:
>Hi all,
>
>Today jlanda, austinpowered and mizdebsk discussed about ticket
>https://pagure.io/fedora-infrastructure/issue/8157 in #fedora-admin and
>came up with a few questions on how to implement that solution that I
>think
>would be nice to share with the wider group.
>
>There are basically 2 possibility :
>
>1 - We run ansible-report as a pre-commit hook
>This means that ansible-report will be run locally before a contributor
>commit a change. This is not ideal since our contributor are running
>all
>kind systems (rhel, fedora, windows ?) so having something that work
>well
>for everyone will not be simple. Also this forces our contributors to
>install ansible-report locally.
>
>2 - We run ansible-report as a pre-receive hook
>This means that ansible-report is run on batcave01, but we cannot run
>ansible-report just on a commit, we need to run the tool against the
>full
>repository every time. That involve making a clone of the repo applying
>the
>changes in the incoming commit, then run ansible-report on that
>repository.
>
>This has also a few disadvantages, first we first need to clear all the
>errors reported by ansible-report in our repo before we enable the hook
>otherwise all commits will be rejected. It will also slows down every
>pushes (time to clone, apply patch, run the tool).
>
>Do people have other ideas ? Is this change worth the trouble ?
>
>Thanks

Julen Landa Alustiza 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

ansible-report git hook design

[Clement Verna]

Hi all,

Today jlanda, austinpowered and mizdebsk discussed about ticket
https://pagure.io/fedora-infrastructure/issue/8157 in #fedora-admin and
came up with a few questions on how to implement that solution that I think
would be nice to share with the wider group.

There are basically 2 possibility :

1 - We run ansible-report as a pre-commit hook
This means that ansible-report will be run locally before a contributor
commit a change. This is not ideal since our contributor are running all
kind systems (rhel, fedora, windows ?) so having something that work well
for everyone will not be simple. Also this forces our contributors to
install ansible-report locally.

2 - We run ansible-report as a pre-receive hook
This means that ansible-report is run on batcave01, but we cannot run
ansible-report just on a commit, we need to run the tool against the full
repository every time. That involve making a clone of the repo applying the
changes in the incoming commit, then run ansible-report on that repository.

This has also a few disadvantages, first we first need to clear all the
errors reported by ansible-report in our repo before we enable the hook
otherwise all commits will be rejected. It will also slows down every
pushes (time to clone, apply patch, run the tool).

Do people have other ideas ? Is this change worth the trouble ?

Thanks
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org