Hi,
Our team uses the CentOS CI infrastructure together within GitHub PR to check those to be in shape. At times it happens that due to programming mistakes we would like to cancel/abort jobs. As those runs take usually up to 45 minutes or even longer or sometimes are just stuck because they are waiting for user input that ofc never is going to happen.
Is there some way to stop them?
In this particular case I am talking about the leapp-to project @ github ( https://github.com/leapp-to/prototype )
Thanks
-- Vinzenz Feenstra Senior Software Developer Red Hat Czech
On 16/06/17 08:09, Vinzenz Feenstra wrote:
Hi,
Our team uses the CentOS CI infrastructure together within GitHub PR to check those to be in shape. At times it happens that due to programming mistakes we would like to cancel/abort jobs. As those runs take usually up to 45 minutes or even longer or sometimes are just stuck because they are waiting for user input that ofc never is going to happen.
Is there some way to stop them?
In this particular case I am talking about the leapp-to project @ github ( https://github.com/leapp-to/prototype )
Thanks
-- Vinzenz Feenstra Senior Software Developer Red Hat Czech
Hi,
When we started the CI project, Jenkins was configured to use its internal auth DB for users/groups. Jenkins let fine tune rights and there is one like Job/Cancel that can be granted. It was after a certain time decided to not create users/groups anymore at the Jenkins level to let $projects create their jobs, but rather use JJB so that $projects would not have to do anything on Jenkins itself, but their jobs would be added/updated/etc through PR for JJB
With that specific use case in mind, I'm wondering if the best way would not to be linking jenkins with https://accounts.centos.org for authentication/group membership. Jenkins supports SSO through openid, which we already have in place for ACO.
For example, for the QA team, we have another jenkins setup (different from the CI env) that is using ACO as authentication source, so people are authenticated through SSO/OpenID
Would it be useful to consider doing the same for CI ? From my personal side, it would make sense to reflect all accounts/users/groups/rights at a single place (SSO FTW) and "just" use it transparently within Jenkins
Not an expert in Jenkins though, so maybe there are other alternatives for that.
Opinions on this ?
On 16/06/17 07:09, Vinzenz Feenstra wrote:
Hi,
Our team uses the CentOS CI infrastructure together within GitHub PR to check those to be in shape. At times it happens that due to programming mistakes we would like to cancel/abort jobs. As those runs take usually up to 45 minutes or even longer or sometimes are just stuck because they are waiting for user input that ofc never is going to happen.
Is there some way to stop them?
One option is to not care. Once the job is running, let it run through to fail.
Whats important then is to ensure your job's are not serialized. I see you have 4 workers enabled, we can add more worker threads if needed - but it might also be useful to enable multi-jobs so multiple CI runs for the same job can be executed in parallel.
That way, if you have a fix in 5 min, you can just request a new ci run, which should start right away, not needing to wait for the first one to finish.
Would that help work around this specific issue ? If so, we can look at the configs to see how best to implement it. Typically, this is just a case of turning on a single line in the JJB.
On Jun 16, 2017, at 3:46 PM, Karanbir Singh kbsingh@centos.org wrote:
On 16/06/17 07:09, Vinzenz Feenstra wrote:
Hi,
Our team uses the CentOS CI infrastructure together within GitHub PR to check those to be in shape. At times it happens that due to programming mistakes we would like to cancel/abort jobs. As those runs take usually up to 45 minutes or even longer or sometimes are just stuck because they are waiting for user input that ofc never is going to happen.
Is there some way to stop them?
One option is to not care. Once the job is running, let it run through to fail.
Whats important then is to ensure your job's are not serialized. I see you have 4 workers enabled, we can add more worker threads if needed - but it might also be useful to enable multi-jobs so multiple CI runs for the same job can be executed in parallel.
That way, if you have a fix in 5 min, you can just request a new ci run, which should start right away, not needing to wait for the first one to finish.
Would that help work around this specific issue ? If so, we can look at the configs to see how best to implement it. Typically, this is just a case of turning on a single line in the JJB.
Yes, it would definitely help us to have them not serialized. the JJB is this? https://github.com/leapp-to/prototype/blob/master/centos-ci/jobs/integration... https://github.com/leapp-to/prototype/blob/master/centos-ci/jobs/integration_test.yml
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
-- Vinzenz Feenstra Senior Software Developer Red Hat Czech
On 16/06/17 14:49, Vinzenz Feenstra wrote:
Yes, it would definitely help us to have them not serialized. the JJB is this? https://github.com/leapp-to/prototype/blob/master/centos-ci/jobs/integration...
sent you a little PR,
but i cant find the service-job corresponding to this, do you know where / how that is setup ?
regards,
Sent from my iPhone
On 16 Jun 2017, at 16:49, Karanbir Singh kbsingh@centos.org wrote:
On 16/06/17 14:49, Vinzenz Feenstra wrote: Yes, it would definitely help us to have them not serialized. the JJB is this? https://github.com/leapp-to/prototype/blob/master/centos-ci/jobs/integration...
sent you a little PR,
but i cant find the service-job corresponding to this, do you know where / how that is setup ?
Pavel can you help out here? I am not sure where it is.
regards,
-- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
On Fri, 2017-06-16 at 17:27 +0200, Vinzenz Feenstra wrote:
Sent from my iPhone
On 16 Jun 2017, at 16:49, Karanbir Singh kbsingh@centos.org wrote:
On 16/06/17 14:49, Vinzenz Feenstra wrote: Yes, it would definitely help us to have them not serialized. the JJB is this? https://github.com/leapp-to/prototype/blob/master/centos-ci /jobs/integration_test.yml
sent you a little PR,
but i cant find the service-job corresponding to this, do you know where / how that is setup ?
Pavel can you help out here? I am not sure where it is.
No idea as well /cc bstinson
regards,
-- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jun 19 01:34, Pavel Odvody wrote:
On Fri, 2017-06-16 at 17:27 +0200, Vinzenz Feenstra wrote:
Sent from my iPhone
On 16 Jun 2017, at 16:49, Karanbir Singh kbsingh@centos.org wrote:
On 16/06/17 14:49, Vinzenz Feenstra wrote: Yes, it would definitely help us to have them not serialized. the JJB is this? https://github.com/leapp-to/prototype/blob/master/centos-ci /jobs/integration_test.yml
sent you a little PR,
but i cant find the service-job corresponding to this, do you know where / how that is setup ?
Pavel can you help out here? I am not sure where it is.
No idea as well /cc bstinson
regards,
-- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
-- Pavel Odvody podvody@redhat.com Sr. Software Engineer - Platform Engineering 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
This is in our admin operations folder. Looks like it didn't get triggered when the PR was merged. I'll take a look.
- --Brian
-
Brian Stinson -
Fabian Arrotin -
Karanbir Singh -
Pavel Odvody -
Vinzenz Feenstra