Post build in Jenkins with last parameters - jenkins

I would like to know if is possible to set a post build triggering the job with the last parameters. I've found this plugin https://wiki.jenkins-ci.org/display/JENKINS/Rebuild+Plugin but I can't have a properly way to call, this plugin is based on last job index.
It's a short question but I was not able to find a properly fix / workaround for that.

I think you must save this parameters in some file in workspace folder for example settings.xml or something similar, you can in easy way make command like this:
sh """echo '<name>$PARAMETER_VALUE</name>' >> ./settings.xml"""
When you would like to read this parameter you could use sed option or something else like:
sh """awk '{if($1 == "name") print $2}' ./settings.xml"""

Related

Jenkins Extended Choice Parameter with groovy shell command

I try to collect data for an Extended Choice Paramater.
I use the code:
def ingo = sh(script: 'mktemp', returnStdout: true)
return ingo
inside the groovy script part, but it seem that this is not allowed or well formated.
The choice is always empty. Anybody has some experience with shell command inside this part of the pipeline?
Sense is, I want to collect data with curl here. But simple shell query is not working.
Please see image
You can't execute Jenkins steps within the Extended Choice Parameter. You have to use pure Groovy within the Parameter. For example, if you want to do an HTTP call you can use a Groovy script like below. Here I'm fetching content from a GitHub file. A Full example can be found here.
def content = new URL ("https://raw.githubusercontent.com/xxx/sample/main/testdir/hosts").getText()

Can I get the arguments passed to bazel itself?

I want to create some "build traceability" functionality, and include the actual bazel command that was run to produce one of my build artifacts. So if the user did this:
bazel run //foo/bar:baz --config=blah
I want to actually get the string "bazel run //foo/bar:baz --config=blah" and write that to a file during the build. Is this possible?
Stamping is the "correct" way to get information like that into a Bazel build. Note the implications around caching though. You could also just write a wrapper script that puts the command line into a file or environment variable. Details of each approach below.
I can think of three ways to get the information you want via stamping, each with differing tradeoffs.
First way: Hijack --embed_label. This shows up in the BUILD_EMBED_LABEL stamping key. You'd add a line like build:blah --embed_label blah in your .bazelrc. This is easy, but that label is often used for things like release_50, which you might want to preserve.
Second way: hijack the hostname or username. These show up in the BUILD_HOST and BUILD_USER stamping keys. On Linux, you can write a shell script at tools/bazel which will automatically be used to wrap bazel invocations. In that shell script, you can use unshare --uts --map-root-user, which will work if the machine is set up to enable bazel's sandboxing. Inside that new namespace, you can easily change the hostname and then exec the real bazel binary, like the default /usr/bin/bazel shell script does. That shell script has full access to the command line, so it can encode any information you want.
Third way: put it into an environment variable and have a custom --workspace_status_command that extracts it into a stamping key. Add a line like build:blah --action_env=MY_BUILD_STYLE=blah to your .bazelrc, and then do echo STABLE_MY_BUILD_STYLE ${MY_BUILD_STYLE} in your workspace status script. If you want the full command line, you could have a tools/bazel wrapper script put that into an environment variable, and then use build --action_env=MY_BUILD_STYLE to preserve the value and pass it to all the actions.
Once you pick a stamping key to use, src/test/shell/integration/stamping_test.sh in the Bazel source tree is a good example of writing stamp information to a file. Something like this:
genrule(
name = "stamped",
outs = ["stamped.txt"],
cmd = "grep BUILD_EMBED_LABEL bazel-out/volatile-status.txt | cut -d ' ' -f 2 >\$#",
stamp = True,
)
If you want to do it without stamping, just write the information to a file in the source tree in a tools/bazel wrapper. You'd want to put that file in your .gitignore, of course. echo "$#" > cli_args is all it takes to dump them to a file, and then you can use that as a source file like normal in your build. This approach is simplest, but interacts the most poorly with Bazel's caching, because everything that depends on that file will be rebuilt every time with no way to control it.

Using git branch in environment variable in Jenkinsfile

I would like to customize one of environment variable depending on branch that is being build.
environment {
CUSTOM_ENV='xyz_${GIT_BRANCH}'
}
I'd like to get CUSTOM_ENV=xyz_dev for origin/dev and CUSTOM_ENV=xyz_master for origin/master. Not sure if its important, but its multibranch project in Jenkins.
I tried things like xyz_${GIT_BRANCH} or xyz_env.GIT_BRANCH, but none of this worked out.
If your shell happens to be compatible with ksh or bash then you can use the variable-expansion modifier ## to discard everything up to and including the final / character, leaving get just the part of ${GIT_BRANCH} that comes after that /. That would look like:
CUSTOM_ENV="xyz_${GIT_BRANCH##*/}"
Note the double-quotes " rather than the single-quotes ' you used in your question. Single-quotes prevent the evaluation of variables inside the quoted string, and that's definitely not what you want in this case.
If your shell does not understand the ## modifier then you'll have to use something like sed to get just the last part of ${GIT_BRANCH}. That would look like this:
CUSTOM_ENV="xyz_$(echo ${GIT_BRANCH} | sed -e 's#.*/##')"
When you are doing a substitution in jenkinsfile for a variable. It should always be in "". From environment directive , I guess you are using pipelines. So, you can leverage the groovy syntax to achieve string manipulation.
Something like,
environment {
GIT_BRANCH = 'orgin/master'.split('/')[1]
CUSTOM_ENV="xyz_${GIT_BRANCH}"
}

How to select the parameter coming from script output and pass it to next script or job in Bamboo?

I am trying to do below things in bamboo.I have script which basically shows the branches of hg repository.I know there is a plugin in Jenkins where you can run the script and get the output and use that output as a parameter to the job/script but I am not sure how to achieve this in Bamboo.Is there any plugin or some way to achieve this?
script abc.py which gives the below output
a
b
c
d
e
f
g
I want this script will run and it will give me the above output and then I can select anyone of them and pass it to my script.The value of the createBranch should come from the script so I can select any one of them
With Bamboo, it is impossible to create/change a variable value from within tasks due to concurrency issues it might create. There is a feature request open for this.
As a workaround, how about writing the script result out to a text file, then read it in from the file using Inject Variables plugin task. You can use this as a variable within the same stage to create a branch in your case.
Hope that helps.

How can I pass variables to post-build actions in Jenkins?

I am trying to send an email in a post-build action, with the content set to some results I computed in a build action. I cannot seem to be able to pass variables from the shell code to any post-build actions.
I have tried with EnvInject, but haven't managed to make it work.
What am I missing?
As it always happens, I managed to find the solution right after I posted the question.
I managed to solve it by having something like this in the shell script bit:
EMAIL_CONTENT=$(cat <<EOF
Some content here.
Some content there.
EOF
)
EMAIL_RECIPIENTS="someone#example.com"
touch email_properties
echo "EMAIL_CONTENT=${EMAIL_CONTENT}" >> email_properties
echo "EMAIL_RECIPIENTS=${EMAIL_RECIPIENTS}" >> email_properties
And then, in the post-build action, I used Trigger parametrized build on other projects, with the Parameters from properties file option in order to trigger some other job whose only purpose is to email me those credentials. It's a bit of a work around, but it works.

Resources