Hi there,
One of the pain points I have with using ci.centos.org is that whenever you want to configure a new repository, you have to wait for `centos-ci` to accept the invitation.
This can take a few days, and I usually have to create a bug in bug.centos.org on behalf of the developers to raise awareness that we're waiting for this.
I was wondering if we could improve this workflow.
I suggest we host a repo under `github.org/centos` with a yaml file with whitelisted repositories. This way as soon as anyone with permissions, such as Brian or KB, merges a PR that includes a new whitelisted repo, it will trigger a job that automatically accepts that repository invitation on behalf of the `centos-ci` user. I like this workflow because merges can be done very quickly, and even from a cell phone ;) It also provides a platform to discuss with the developers in case there are any questions about the repo, etc, plus added auditability, etc.
Note that the old workflow would continue to work, i.e. having the repo in the whitelist file is not strictly required as invitations can still be manually handled. But if users actually send a PR it will be faster for them. Therefore, if we go forward, I suggest we add a note in this doc about how to accelerate the accepting of invitations by sending a PR: https://wiki.centos.org/QaWiki/CI/GithubIntegration
I put together this script as a PoC: https://github.com/jmelis/automate-invitations
What do you guys think?
cheers, Jaime
On Sep 08 21:18, Jaime Melis wrote:
Hi there,
One of the pain points I have with using ci.centos.org is that whenever you want to configure a new repository, you have to wait for `centos-ci` to accept the invitation.
This can take a few days, and I usually have to create a bug in bug.centos.org on behalf of the developers to raise awareness that we're waiting for this.
I was wondering if we could improve this workflow.
I suggest we host a repo under `github.org/centos` with a yaml file with whitelisted repositories. This way as soon as anyone with permissions, such as Brian or KB, merges a PR that includes a new whitelisted repo, it will trigger a job that automatically accepts that repository invitation on behalf of the `centos-ci` user. I like this workflow because merges can be done very quickly, and even from a cell phone ;) It also provides a platform to discuss with the developers in case there are any questions about the repo, etc, plus added auditability, etc.
Note that the old workflow would continue to work, i.e. having the repo in the whitelist file is not strictly required as invitations can still be manually handled. But if users actually send a PR it will be faster for them. Therefore, if we go forward, I suggest we add a note in this doc about how to accelerate the accepting of invitations by sending a PR: https://wiki.centos.org/QaWiki/CI/GithubIntegration
I put together this script as a PoC: https://github.com/jmelis/automate-invitations
What do you guys think?
cheers, Jaime
-- Jaime Melis Senior Software Engineer, OpenShift.io Red Hat jmelis@redhat.com _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
This workflow looks ok to me. I don't mind accepting invitations this way.
Have you counted the number of Github API calls that accept_invitations() makes? I'm curious if it would make 1 or more calls per repo listed in the yaml file, that may be something we can optimize for.
--Brian
Hi Brian,
Well, it will only make 1 API call if there is a pending invitation and if the repo is in the yaml file. So, once it's accepted it will not make any more API calls for that repo, regardless if it's in the yaml file or not. I think that's what you're asking?
On Mon, Sep 10, 2018 at 3:28 PM Brian Stinson brian@bstinson.com wrote:
On Sep 08 21:18, Jaime Melis wrote:
Hi there,
One of the pain points I have with using ci.centos.org is that whenever you want to configure a new repository, you have to wait for `centos-ci` to accept the invitation.
This can take a few days, and I usually have to create a bug in bug.centos.org on behalf of the developers to raise awareness that we're waiting for this.
I was wondering if we could improve this workflow.
I suggest we host a repo under `github.org/centos` with a yaml file with whitelisted repositories. This way as soon as anyone with permissions, such as Brian or KB, merges a PR that includes a new whitelisted repo, it will trigger a job that automatically accepts that repository invitation on behalf of the `centos-ci` user. I like this workflow because merges can be done very quickly, and even from a cell phone ;) It also provides a platform to discuss with the developers in case there are any questions about the repo, etc, plus added auditability, etc.
Note that the old workflow would continue to work, i.e. having the repo in the whitelist file is not strictly required as invitations can still be manually handled. But if users actually send a PR it will be faster for them. Therefore, if we go forward, I suggest we add a note in this doc about how to accelerate the accepting of invitations by sending a PR: https://wiki.centos.org/QaWiki/CI/GithubIntegration
I put together this script as a PoC: https://github.com/jmelis/automate-invitations
What do you guys think?
cheers, Jaime
-- Jaime Melis Senior Software Engineer, OpenShift.io Red Hat jmelis@redhat.com _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
This workflow looks ok to me. I don't mind accepting invitations this way.
Have you counted the number of Github API calls that accept_invitations() makes? I'm curious if it would make 1 or more calls per repo listed in the yaml file, that may be something we can optimize for.
--Brian
-- Jaime Melis Senior Software Engineer, OpenShift.io Red Hat jmelis@redhat.com
A couple of follow up questions:
Would it make sense to have a whitelist_org key? That is, automatically accept any **repo** invitations (not org invitations) if the repo belongs to a specific org?
Also, I would like to write a small PR check script, so you or anyone else with permissions can quickly determine whether or not to merge the PR. I was thinking about retrieving the following info:
- Repo description - Repo creation date - Inviter profile (link to the profile, creation date, and basic stuff like email if defined, etc)
Unsure if we can get all those stats, but any other suggestions that can make your life easier to determine whether to merge the PR?
cheers, Jaime
On Mon, Sep 10, 2018 at 3:52 PM Jaime Melis jmelis@redhat.com wrote:
Hi Brian,
Well, it will only make 1 API call if there is a pending invitation and if the repo is in the yaml file. So, once it's accepted it will not make any more API calls for that repo, regardless if it's in the yaml file or not. I think that's what you're asking?
On Mon, Sep 10, 2018 at 3:28 PM Brian Stinson brian@bstinson.com wrote:
On Sep 08 21:18, Jaime Melis wrote:
Hi there,
One of the pain points I have with using ci.centos.org is that whenever you want to configure a new repository, you have to wait for `centos-ci` to accept the invitation.
This can take a few days, and I usually have to create a bug in bug.centos.org on behalf of the developers to raise awareness that we're waiting for this.
I was wondering if we could improve this workflow.
I suggest we host a repo under `github.org/centos` with a yaml file with whitelisted repositories. This way as soon as anyone with permissions, such as Brian or KB, merges a PR that includes a new whitelisted repo, it will trigger a job that automatically accepts that repository invitation on behalf of the `centos-ci` user. I like this workflow because merges can be done very quickly, and even from a cell phone ;) It also provides a platform to discuss with the developers in case there are any questions about the repo, etc, plus added auditability, etc.
Note that the old workflow would continue to work, i.e. having the repo in the whitelist file is not strictly required as invitations can still be manually handled. But if users actually send a PR it will be faster for them. Therefore, if we go forward, I suggest we add a note in this doc about how to accelerate the accepting of invitations by sending a PR: https://wiki.centos.org/QaWiki/CI/GithubIntegration
I put together this script as a PoC: https://github.com/jmelis/automate-invitations
What do you guys think?
cheers, Jaime
-- Jaime Melis Senior Software Engineer, OpenShift.io Red Hat jmelis@redhat.com _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
This workflow looks ok to me. I don't mind accepting invitations this way.
Have you counted the number of Github API calls that accept_invitations() makes? I'm curious if it would make 1 or more calls per repo listed in the yaml file, that may be something we can optimize for.
--Brian
-- Jaime Melis Senior Software Engineer, OpenShift.io Red Hat jmelis@redhat.com
-
Brian Stinson -
Jaime Melis