Using Pipeline you would take a different approach, like having a common
script in source control that all the jobs could use to accomplish the
common task.
I'm surprised that the Template plugin is not working for you, however.
We're not at the very latest LTS but at 2.204.5, and it works fine for
us. We use it in hundreds of jobs. A quick look at your stack trace
suggests you are missing the Multiple SCM plugin as a dependency.
Regards,
Eric
On 6/4/2020 11:42 AM, Alberto Scotto wrote:
Thanks Eric, I appreciate it.
Unfortunately the template plugin seems not be up-to-date.
I've just opened a new issue on JIRA, but I'm not really hopeful..
https://issues.jenkins-ci.org/browse/JENKINS-62568
I noticed there seems to be a couple more template plugins, I might
give them a try.
Assuming you are using a Freestyle project (not Pipeline)
What if we were to use Pipeline? Would it make things easier?
Thank you
Alberto
Il giorno venerdì 29 maggio 2020 00:17:42 UTC+2, Eric Pyle ha scritto:
Assuming you are using a Freestyle project (not Pipeline) you
could use the Template Project Plugin
https://plugins.jenkins.io/template-project/
<https://plugins.jenkins.io/template-project/>. You create a
template job which contains all the common functionality, and then
in the separate job for each environment you add the template job
as a build step (Use builders from another project).
-Eric
On 5/28/2020 7:39 AM, Alberto Scotto wrote:
Hi,
Long story short: is it possible to have a job which builds
another job, in particular a parametrized one?
We have a Cucumber+Selenium project which runs E2E tests against
our different test environments.
Something pretty standard.
For this kind of job, the parametrized build seems to be the best
idea.
Otherwise we would have to create one job for each test
environment. duplicating the job configuration.
Then it would be a nightmare to keep all the job configurations
in sync, in case we need to change something.
But there's a problem with the build history.
I want to see a separate build history for each environment.
It doesn't make sense to have an interleaved history. It would be
messy.
So an easy solution could be to have a job which calls the
parametrized job passing the actual value for the environment.
This way the build histories would be kept separate, and at the
same time we would also get to avoid duplication.
Is that possible? Or do you have any other idea/solution?
Thank you very much.
Alberto
--
You received this message because you are subscribed to the
Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to jenkins...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/5f64c8d1-db57-4002-9aa7-5e574638b76c%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-users/5f64c8d1-db57-4002-9aa7-5e574638b76c%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-users+unsubscr...@googlegroups.com
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/b75ccb32-b748-4af1-8331-ace29a2c6074%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-users/b75ccb32-b748-4af1-8331-ace29a2c6074%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "Jenkins
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/cbde6bf8-45e1-8fa0-1b73-dabf63bd6fc0%40cd-adapco.com.
