I want to pass the Build Name and the BUILD ID to the REST API using Jenkins HTTP POST plugin
how to pass the parameters to it?
I am passing:
http://localhost:55223/api/Demo?BuildName=${JOB_NAME}&BuildID=${BUILD_ID}
I am receiving an error
It looks like the Plugin does not expand environment variables, as evidenced by it's source code. As the plugin has not been updated in 2 years, I don't think there's any chance of the developer adding this anytime soon. If you are still wanting to use the plugin, you could make the changes changes necessary to expand the environment variables and then build it from source. For that, I would recommend looking at the Jenkins classes hudson.EnvVars and hudson.model.Run. More specifically, the Run method getEnvironment(TaskListener listener) and the EnvVars method expand(String s).
Related
I couldn't find any solutions to this particular need.
Basically I have a GUI Job and I need the status of the Sonarqube Analysis so I can later send a POST Request with it.
(I'm aware that pipeline exists and works great but because a specific reason I need it to be GUI)
On the pipeline you have the WaitForQualityGate.status(), I've tried using this but no success.
Example of what is desired
Any insights? Thanks in advance
You can use the SonarQube Rest API to get the status.
Whenever you run SonarQube analysis through Jenkins Pipeline, upon the successful analysis you will see report-task.txt created in the workspace folder.
Note: The location of report-task.txt file depends on the tool that was used to generate it. The mvn sonar:sonar task defaults to path target/sonar. In my case, I used sonarscanner to analyse a nodejs project. So the location of report-tast.txt is .scannerwork.
Now, you will get the ceTaskUrl and ceTaskId in report-task.txt. You can use that ceTaskUrl to get the analysisId.
Then, you can use the below api to get the quality gate status using analysisId.
http://<sonarqube_host>/api/qualitygates/project_status?analysisId=$ANALYSIS_ID"
Now, try to get the curl output of the above API into a variable.
If you mean to say that you want a custom variable message to pop up in your Jenkins GUI based on the SonarQube scan status, then that would require you to:
Clone the original Jenkins source code
Add a custom HTML button/div/graphic
Compile the Jenkins code
Build the new code
Execute the generated JAR
Else, you can try some plugins available on Jenkins that would give you the ability to render conditional outputs. No promises on whether they can actually help you change the original GUI.
Any alternative traditional approach wouldn't be able to fulfill your GUI requirement.
A project repository has been successfully connected to a Jenkins server using the BitBucket plugin, and a project set up such that:
Each push to a branch in BitBucket will trigger a webhook sent to the Jenkins server
When the Jenkins server receives the webhook it will build the changed branch (by specifying branch name as ** in the config)
After the build is complete a notification is sent back to BitBucket of the build status using the BitBucket notifier
Each of these has been easy to set up with just the instructions in the plugin and a few quick Googles. However I've now run into a problem which is maybe more a matter of wanting to run in an unconventional manner than anything else.
Using the normal emailer plugin or the Email-ext plugin it's possible to set emails to send to people involved in the creation of a build. For example the Email-ext plugin allows choice of:
Requester
Developers (all people who have commits in the build based off its last version)
Recipient list (a pre-set list)
Various "blame" settings for broken builds
The development process being followed involves each project being worked on by one developer in a named branch, e.g. userA/projectB. Obviously other developers could check that out and push to make changes but that's frowned upon. Even in that instance, the user who pushes the change to BitBucket should be notified.
None of the current settings support this. Requester is the closest, but that only works for manual builds. It seems a very simple requirement that the push to SCM that triggered a build should notify the user who pushed, but this is not documented anywhere that is easy to find.
After a lot of searching it seems the only way to accomplish this is by using a Pre-send script. This is added to the Advanced setting of the Email-ext post-build step, and takes the form of code written in Groovy which is a Java extension.
The script can take advantage of Environment variables, but is hard to test as there's no way to run the script with these in place. You can test simple Groovy scripts from Home -> Manage Jenkins -> Script console.
One important "gotcha" with the environment variables is that they are "included" in the script, rather than variables or constants. E.g. before the script compiles and runs, the content of the variable is pasted in place of its $NAME. In the example below the multi-line string syntax is used to include the BitBicket payload, whereas it might be expected that def payload = $BITBUCKET_PAYLOAD would simply work.
import javax.mail.Message.RecipientType
import javax.mail.Address
import javax.mail.internet.InternetAddress
import javax.mail.internet.MimeMessage
import groovy.json.JsonSlurper
def jsonSlurper = new JsonSlurper()
def bitbucket = jsonSlurper.parseText('''
$BITBUCKET_PAYLOAD'''
)
switch (bitbucket.actor.username){
case "userA":
msg.setRecipients(MimeMessage.RecipientType.TO, InternetAddress.parse("user.a#domain.com"));
break;
case "userB":
msg.setRecipients(MimeMessage.RecipientType.TO, InternetAddress.parse("user.b#domain.com"));
break;
}
The setRecipients command overwrites any existing recipient. Thus the recipient list or other email configuration should be set as a fallback for if the user is not recognised. Additionally, if there is nobody selected to send the email to, the script won't run at all. As added debugging, including the username in the body might help.
If the script fails, stack traces should be printed to the console log output of the test, and the build pass/fail shouldn't be affected, but the normal email address setup will be used instead. In stack traces look for lines with Script() in them, as that's the container which evaluates the Groovy script.
I have the Stash pull request builder plugin working great in Jenkins, it see's a pull request and kicks off the Jenkins job which runs some tests and puts a generic comment on the pull request saying pass or fail.
The problem I'm having is when the plugin comments back to the pull request I'd like to use a variable I create in the post build section, I've tried creating the variable as an environment variable but it seems the comments part of the plugin can only see the built in Jenkins variables like ${BUILD_NUMBER} anything else just prints out the name directly.
I've had a look at envinject, but I'm not sure how to set a variable from it in the post build section, or even if the variables it creates would be seen by the Pull Request Builder Plugin.
I did a quick test with my Jenkins/Stash platform.
I have a job using this custom variable:
I've added a post-build step to publish a custom comment:
We can see that my SCM_REVISION environment variable is displayed in Stash:
I hope it helped :)
Is there a way to get the hudson job initiated user name.
Is it possible to get using script shell, py etc.
Lets assume I have the build # which was initiated. I know how to get the latest build info using api but would like to get a user details for a specific job.
Do you think, this will work for hudson? :)
https://wiki.jenkins-ci.org/display/JENKINS/Build+User+Vars+Plugin
Thanks in advance
That plugin will not work with Hudson, unless you download a very old version of the plugin. I'm not sure how many people are still using Hudson and haven't upgraded to Jenkins.
Anyway, when a user manually triggers a build, this is called a "user cause"; there are other types of cause, e.g. SCM trigger.
You can use the JSON or XML API to get the causes for a build, for example:
https://ci.jenkins-ci.org/job/remoting/lastSuccessfulBuild/api/xml?xpath=//action/cause/userId
In this case, this returns the username that caused the build to run.
Though note that there may be multiple causes for a build, and potentially other cause types that use the userId field.
This works in Jenkins, but it should also work in Hudson, but I haven't tested it.
I'm constructing some build scripts using FAKE for a TeamCity setup. Part of my build requires me to access the teamcity.build.branch parameter, however because it's not an environment variable, I'm not sure how to access it.
I've tried adding %teamcity.build.branch% to an environment variable in TeamCity but it doesn't seem to like that. I also can't access it using the FAKE git module because team city agents don't use git to get the project files, TeamCity hands it to them.
How would I go about getting the teamcity.build.branch parameter through to my FAKE scripts? Ideally I'd like it as an environment variable so I can pick it up straight from within the script, but I'm open to any other ideas.
Try passing %teamcity.build.branch% as a parameter in your build step.
I figured it out with a bit of help from #Nadeem's answer.
I now have my build.bat/cmd file taking in a parameter which I'm then passing into my Fake.exe call like so:
"packages\FAKE\tools\Fake.exe" build.fsx branch=%1
Then inside my FAKE code I'm using the getBuildParamOrDefault "branch" <default branch here>.
I'm then using this as the branch name. I'm also using a string split on the build param that comes in because normally it's in the format of ref/head/<branch name> and I only want the branch name.
I also had to pass in %teamcity.build.vcs.branch.<project>% instead of %teamcity.build.branch% as my agents didn't like the implicit requirement. I'm not entire sure why this is but all is working well now.