On Thu 3 Aug 2017 at 21:09, bbyjenkns wrote:
> You can't use normal groovy api since it only works on master. Since
>> you're already using unix slaves, just use a normal shell step will save
>> you headaches.
>
>
> Why does the groovy api only work on master, but the sh step
I should mention that I'm specifically trying to perform file operations
within a workspace using global pipeline libraries. I'm not following how a
global pipeline library would even make sense if it can only run on master
- am I missing something here?
On Thursday, August 3, 2017 at 3:06:23
>
> You can't use normal groovy api since it only works on master. Since
> you're already using unix slaves, just use a normal shell step will save
> you headaches.
Why does the groovy api only work on master, but the sh step does? What is
the point of having a global pipeline if it can
Thank you Sam, Will take a shot on this and get back.
On Monday, 31 July 2017 14:24:44 UTC-7, Sam K wrote:
>
> Hi
>
> I'm not saying this is the best way...
>
> You can add the feature to kick off jobs remotely using a token. Then
> you can somehow grab the parameters of the job. For
The secret text being printed as *** is a feature, so credentials aren't
leaked in console logs. You cannot use Jenkins credentials during
application runtime. (ie: If you deploy a backend Node app to an app
server) You can however use Jenkins credentials to run npm scripts, such as
npm test,
That's right... to define, it is something like:
parameters {
string(name: 'bld', defaultValue: 'full', description: '')
string(name: 'branch', defaultValue: 'dev', description: '')
}
you may load some properties from a file and use those variables for
defaultValue...
Hi Community,
I'm unable to pass parameters from Jenkins to remote shell script.
These (3) parameters are;
${DATABASE}
${SCHEMA}
${COMMENT}
I have a Jenkins project that uses a slave machine (sys-07) to run shell
scripts on a remote host (raloda10).
The shell script
Hi Michael -- I finally go around to upgrading as well and am facing the
same problem. Have you worked around this? Are you just supplying the XML
directly?
On Tuesday, July 11, 2017 at 8:39:29 PM UTC-4, Michael Kobit wrote:
>
> Finally got some time to try it out (sorry!) and I know the PR
I have a new Jenkins installation (deployed in Tomcat), and I defined the
Jenkins home directory to:
/srv/webapps/jenkins
Maven Jobs seem to not be able to deal with this (even though it is
the home directory defined in the configuration).
They also don't respect the definition in the global
Hi All, I just installed this plugin and am excited to use it but ...
the Build Time Blame Report does not come up in the left menu on every
build (but on most)
and on most builds it only has the latest build info (do I have to display
the report once before it will do multiple future builds?)
Seems that your lint output file uses a different format. The JSLint parser
expects an XML file… Is there an option to change the format in jslint?
> Am 03.08.2017 um 09:08 schrieb swarna~~ :
>
> I have a project in which JSLint parses the log file which contains
I my pipeline I use properties of ParentJob (the job that triggered current
job) multiple times.
I wrote script to evaluate it, but it order to do this only once, I wanted
to store it in property outside pipeline, unfortunately this
brings NotSerializableException regardless that it actually
I have done the following:
1. Create a "secret text" type credential
2. Put in the credential a password
3. Create a Global Variable, mySecret, with its value being the credential
ID
4. In the declarative pipeline:
stage ("E2E tests") {
environment {
mySecret =
I have a project in which JSLint parses the log file which contains the
output of the below command:
( find "" -name "*.js" -print0 | xargs -0 jslint ) >
"${WORKSPACE}/jslint.log" || :
Below is the snippet of the content of the log file:
I already checked that before submitting question :/
It is not stated in the search what should be the settings of Gerrit
Trigger in job ( type of triggers, Branches -> Pattern ).
W dniu środa, 2 sierpnia 2017 17:26:13 UTC+2 użytkownik Victor Martinez
napisał:
>
>
Yes, kind of...
The parameters are hidden in the "properties" structure. They will be
applied to the job when it runs, meaning that the first run will not
have these parameters defined. If you make your Jenkinsfile robust for
undefined parameters, it should be doable, just remember that they
16 matches
Mail list logo