>
> Do you know if all builds from each PR go to the same job that is created
> in the build-a-job step?
>
Yes, indeed. I don't know in your specific use case, but using concurrent
builds you can solve concurrent PR executions if you got enough agents too.
--
You received this message
Use a shared library to define the steps with a common name.
Each branch will just have a Jenkinsfile of
ourStandardBuild();
Then you define two org folders. One for the new build and the other for
the old build.
Add the respective shared library to each org folder.
See Watch Me Code Episodes
Thanks for the quick reply - that's an intriguing proposition!
Do you know if all builds from each PR go to the same job that is created
in the build-a-job step?
On Wednesday, December 13, 2017 at 2:10:45 PM UTC-8, Victor Martinez wrote:
>
> if the old tests will be deprecated and removed
if the old tests will be deprecated and removed sooner than later, cannot
you just use
the
https://jenkins.io/doc/pipeline/steps/pipeline-build-step/#build-build-a-job
step?
Then, the Jenkinsfile will trigger two parallel branches, the first one
about the new tests using whatever is part of
Hello! I am new to Jenkins, and would appreciate help with the following
scenario.
I have been tasked with migrating an existing testing framework to a new
one for my team's CI infrastructure. This resulted in the need for a
rewrite of our current, existing tests. As a result, we now have a
For prosperity, my finding is:
1. it seem like the node have their node name as label automatically (I
realized this when trying to add the node name to the label, the label was
disappearing when saving the changes)
2. Knowning number 1 point, I could just use the named
If you meant about using the promote build plugin, you can add some input
parameters in the job and then use those parameters within the promotion
stage, since they are populated. For instance:
Thanks for the link
How would I specify the destination directory in which the artifacts
should be copied please ?
Le jeudi 7 décembre 2017 18:07:43 UTC+1, Victor Martinez a écrit :
>
> What about using the promote builds plugin
>
Both PROD and test have the same Global Tool Configuration Maven
Configuration (defaults and no publishers configured) and are running the
same versions of Pipeline Maven Integration (3.0.3).
PROD is on Jenkins 2.92 and test on 2.93, so not sure if that and PROD not
restarted after plugin
we are getting the same issue, it is resolved once we restarted the slave
service in the unix client.
but i want to understand what is the root cause for this problem, because
in my case it is failing the git clone operations it self.
On Wednesday, September 5, 2012 at 1:51:44 PM UTC+5:30,
Is prod running an older version of the plugin. Disabling is only a recent
feature. Also see
https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/JENKINS-46785
for a related request about being able to disable default publishers so
that options only specifies the ones you want configured.
Hi
Does any one knows what provides and how to disable Maven not to trigger
"*Maven
Publishers with default configuration*:" info in Console Output?
If I run the same code on 2 different Jenkins instances, one of them do not
have this kind of diferenciation between Maven Publishers set by
There is an interesting blog entry about the jenkins
documentation:
https://jenkins.io/blog/2017/11/27/tutorials-in-the-jenkins-user-documentation/
Cheers
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and
I like the second approach. Thank you.
Am Dienstag, 12. Dezember 2017 20:35:44 UTC+1 schrieb Victor Martinez:
>
> IIRC, you cannot label them but you can use the suggested approach as
> explained here
>
14 matches
Mail list logo
