There is a list of env variables available for GoCD at:
https://docs.gocd.org/current/faq/environment_variables.html
However I'm looking for something like: GO_BUILD_ERROR or similar.
I would like to have the failure reason or message when a build fails to pass this to an external script or message.
There seems to be nothing in the documentation.
GoCD doesn't have any such variables. The reason I feel is mostly because GoCD is very generic in terms of what commands constitute a build for a material. You might want to parse the logs manually to figure that out.
Also in the context of GoCD environment variables are used as input to the stages and not as output from them. If you're planning to build a plugin / wrapper for the commands that run consider storing them as properties in the jobs that way they can also be queried upon later if required.
Related
I'm debugging a problem with atlassian-bitbucket-server-integration-plugin. The behavior occurs when generating a multi-branch pipeline job, which requires a Bitbucket webhook. The plugin works fine when creating the pipeline job from the Jenkins UI. However, when using DSL to create an equivalent job, the plugin errors out attempting to create the webhook.
I've tracked this down to a line in RetryingWebhookHandler:
String jenkinsUrl = jenkinsProvider.get().getRootUrl();
if (isBlank(jenkinsUrl)) {
throw new IllegalArgumentException("Invalid Jenkins base url. Actual - " + jenkinsUrl);
}
The jenkinsUrl is used as the target for the webhook. When the pipeline job is created from the UI, the jenkinsUrl is set as expected. When the pipeline job is created by my DSL in a freeform job, the jenkinsUrl is always null. As a result, the webhook can't be created and the job fails.
I've tried various alternative ways to get the Jenkins root URL, such as static references like Jenkins.get().getRootUrl() and JenkinsLocationConfiguration.get().getUrl(). However, all values come up empty. It seems like the Jenkins context is not available at this point.
I'd like to submit a PR to fix this behavior in the plugin, but I can't come up with anything workable. I am looking for suggestions about the root cause and potential workarounds. For instance:
Is there something specific about the way my freeform job is executed that could cause this?
Is there anything specific to the way jobs are generated from DSL that could cause this?
Is there another mechanism I should be looking at to get the root URL from configuration, which might work better?
Is it possible that this behavior points to a misconfiguration in my Jenkins instance?
If needed, I can share the DSL I'm using to generate the job, but I don't think it's relevant. By commenting out the webhook code that fails, I've confirmed that the DSL generates a job with the correct config.xml underneath. So, the only problem is how to get the right configuration to the plugin so it can set up the webhook.
It turns out that this behavior was caused by a partial misconfiguration of Jenkins.
While debugging problems with broken build links in Bitbucket (pointing me at unconfigured-jenkins-location instead of the real Jenkins URL), I discovered a yellow warning message on the front page of Jenkins which I had missed before, telling me that the root server URL was not set:
Jenkins root URL is empty but is required for the proper operation of many Jenkins features like email notifications, PR status update, and environment variables such as BUILD_URL.
Please provide an accurate value in Jenkins configuration.
This error message had a link to Manage Jenkins > Configure System > Jenkins Location. The correct Jenkins URL actually was set there (I had already double-checked this), but the system admin email address in the same section was not set. When I added a valid email address, the yellow warning went away.
This change fixed both the broken build URL in BitBucket, as well as the problems with my DSL. So, even though it doesn't make much sense, it seems like the missing system admin email address was the root cause of this behavior.
I posted this in the Jenkins users Google group, but thought I'd post it here too.
I have a Jenkins Pipeline job, and in its Configuration page, I use a "Pipeline script from SCM" as my pipeline. One of this block's parameters is "Branch to build" of course. How can I used an environment variable for the text block? I tried, for example, $branchToBuild, ${branchToBuild} or "${branchToBuild}" and it just takes those as literal values and does not interpolate the string. I do have that variable defined and use it in other jobs.
Someone suggested using ${env.branchToBuild}, so I tried env.branchToBuild, $env.branchToBuild, ${env.branchToBuild}, and "${env.branchToBuild}" all to NO avail, that is, they are also just taken as literal strings and not interpolated.
Is it just not possible to do this?
You have to uncheck Lightweight checkout box in order to use a variable as Branch name to build.
It's a known Jenkins bug, here is more information : How to pass project parameter as branch name to build in Jenkins
Apparently the code path is very different if you are using the
lightweight checkout, and that has not been resolved, apparently.
Another source : https://cleverbuilder.com/notes/jenkins-dynamic-git-branch/
Fairly new to the use of Jenkins, but I am looking for a way to get test results and feed it back into Jenkins.
What this means is, I have a bash scripts that collects metrics on a number of applications and checks to see whether or not the files exist. I collect this data to a plain text file, basically with counters 1/5, 2/5, 5/10 etc.
The output can be however I want it, but I was wondering if there is a good/clean process that can take this data file and output it nicely inside of Jenkins web interface?
We also use Trac as well.. so if there is a Trac plugin that can do something similar, that would be good too.
The best practices would say to escape them and use them as parameters to a parameterized jenkins build or a file save/capture. Parameters are finicky and subject to url encoding, so I would personally do file passing using a shared filesystem such as S3. Your best bet is https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API
I've been wondering if it's possible to limit shell commands a user can run in a Jenkins job?
Example: We store an universal password to access our Subversion repositories in Jenkins, and we don't want people to just cat the file, echo it out and display it in the buildlog for the job.
Exactly how can you limit the number of shell commands and directories users can utilize?
This is outside the scope of Jenkins, that's purely your responsibility for addressing this, main reason being that's impossible to do it correct from Jenkins.
There are two solutions
* Start using docker containers as build slaves
* Try to use OS level limitations
Regarding keeping secrets secret the final answer is you cannot really secure it from those writing scripted jobs.
And yes, keep the master isolated for special jobs.
Say I want to run a custom Node script on my DocPad server once a day (like a cron job), where would I put it? I can build a Node script that does stuff after an interval, I'm more curious about where to reference / run the script in the DocPad server.
A plugin is possible, though I've seen that you can require Node libraries within the DocPad configuration file so it could go in there.
Is there a suggested way to approach this?
If you're wanting something purely cron-like, probably using the docpadReady event would be the way to go, doing something like:
docpadReady: ->
require('schedule').every('2 minutes').do ->
require('safeps').spawn('your cron job')
Alternatively, maybe DocPad's regenerateEvery configuration option is suitable. This tells DocPad to regenerate every X millseconds, which will naturally call the generate events that you could hook into.
Alternatively, is there a need for these crons to run on the same server as DocPad? If not, you could do them completely separately.
A final option, is to see if your server you are deploying to supports spawning multiple files. So DocPad's Server is spawned, and so is cron, with DocPad not knowing about the cron task at all.