Jenkins appears to be backed up so I am going to cancel out some long
standing jobs to help it catch back up. Some pull requests and tests will
need to be restarted once Jenkins has caught back up.
Eric
I think the way plugin jobs are run with nine matrix sub-jobs running
nine more test_plugin jobs isn't helping as it quickly leads to
deadlocks, so I've started refactoring them to use just ten jobs.
https://github.com/theforeman/foreman-infra/commit/19b10291 is the
start, and I'll carry on defining more plugins under
puppet/modules/jenkins_job_builder/files/config/yaml/jobs/plugins/ until
they're all migrated.
Thanks for fixing it yesterday Eric.
···
On 01/06/15 21:56, Eric D Helms wrote: > Jenkins appears to be backed up so I am going to cancel out some long > standing jobs to help it catch back up. Some pull requests and tests > will need to be restarted once Jenkins has caught back up.–
Dominic Cleal
Red Hat Engineering
Jenkins matrix vs triggering another job directly is still something I am
getting the hang of. In this instance, are you refactoring to just the
matrix jobs or just triggering jobs directly but with parameters? In other
words, what should our "best practice" goal be when we need to define jobs
like this in the future (or refactoring currently existing ones) to be more
efficient? I think if I get a better handle on this I can look at making
the jobs I've created for various things cleaner.
Thanks for starting the refactoring Dominic – if you need any help please
let me know.
···
On Tue, Jun 2, 2015 at 8:25 AM, Dominic Cleal wrote:On 01/06/15 21:56, Eric D Helms wrote:
Jenkins appears to be backed up so I am going to cancel out some long
standing jobs to help it catch back up. Some pull requests and tests
will need to be restarted once Jenkins has caught back up.I think the way plugin jobs are run with nine matrix sub-jobs running
nine more test_plugin jobs isn’t helping as it quickly leads to
deadlocks, so I’ve started refactoring them to use just ten jobs.Add test_plugin_* template and move bootdisk · theforeman/foreman-infra@19b1029 · GitHub is the
start, and I’ll carry on defining more plugins under
puppet/modules/jenkins_job_builder/files/config/yaml/jobs/plugins/ until
they’re all migrated.Thanks for fixing it yesterday Eric.
–
Dominic Cleal
Red Hat Engineering–
You received this message because you are subscribed to the Google Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> Jenkins matrix vs triggering another job directly is still something I
> am getting the hang of. In this instance, are you refactoring to just
> the matrix jobs or just triggering jobs directly but with parameters?
I'm moving towards a single non-matrix job that triggers a matrix job
with parameters. (test_plugin_foreman_bootdisk_master calls
test_plugin_matrix which splits into nine.)
Previously we had a matrix job that triggered single non-matrix jobs
with parameters, which leads to twice the number of jobs running.
(test_plugin_foreman_bootdisk would split into nine, and each would call
test_plugin.)
> In
> other words, what should our "best practice" goal be when we need to
> define jobs like this in the future (or refactoring currently existing
> ones) to be more efficient? I think if I get a better handle on this I
> can look at making the jobs I've created for various things cleaner.
Probably to try and minimise the use of matrix jobs that then trigger
other jobs, as that's when the numbers start multiplying.
···
On 02/06/15 14:23, Eric D Helms wrote:–
Dominic Cleal
Red Hat Engineering