I have project configured in Jenkins that polls an SCM and begins a build when a change is posted. There is a post build action to build another project. The question I have is, the project that is being built afterwards has its own parameters. How do I know which parameter is specified when the post-build action triggers? Right now if if I use 'Choices', is it just picking the first one? How do I have it pick other ones?
OK, let's take it one by one :)
If you want to see which parameter were used, You can install this plugin: Show Build Parameters Plugin
If you want to trigger a build with a specific parameters, use this plugin: Parameterized Trigger Plugin
Related
I have a project that needs to execute either three or four build steps depending on the branch in source control. More specifically, if I'm merging in a PR and running the build (for GitHub status notifications) I have one extra build step that is required.
It's that last build step that I need to omit if it's a non-PR branch.
Is there a way to add a build step that checks the trigger and exits the build successfully? Or a way to exclude a build step based on a branch filter?
You can check the condition and modify the step logic inside the build script. See the related ticket and an example of the script.
BTW, It is not a good practice to change the logic of the build inside build script. In this case you no longer "compare" builds in the build configuration: they start to form multiple unrelated sequences. Also the statistics of the builds will be uninformative. The recommended setup is to create several build configurations based on template.
Depending on which type of runner you are launching, but you can, in some cases, add few lines of code to get your current branch name with the property : %teamcity.build.branch%
In my case, I just add this as an extra parameter for powershell scripts and if this is a number, do something, else, do other stuff. ;)
TeamCity 8.1.4 (build 30168)
I notice that Build Features are always run as first part of first step in the Build Steps, but is it possible to make a Build Feature run e.g. as first part of step2? Or as last part of Step1?
Any help is appreciated!
(If it is of interest, this is my concrete problem;
I have a meta runner that creates a specific build number, I use this as a first step in the build steps. I want to use the build feature "AssemblyInfo patcher", but this runs before the meta runner has done its thing)
Create another build configuration, move your meta-runner there.
Modify your build parameter to report a build number through service message
Create a snapshot dependency from your build configuration to the new one
In the configuration with meta-runner go to general page, enter %dep.META_RUNNER_CONFIG_ID.build.number% to 'build number' field. This will take a build number from the dependency and set it as a build number. META_RUNNER_CONFIG_ID is the Build configuration id you will see on the general page of your configuration where you have moved meta runner.
Use %build.number% as a replacement in AssemblyInfoPatcher
I'm a Maven noob currently working with Maven/Jenkins to perform some downstream jobs on the back of a release task and my team has hit a problem.
What we are trying to achieve is to pass in the version tag into the downstream jobs once the main build has been executed. We had been trying to achieve this using the M2 plugin, but it appears to execute in a Build->Downstream Jobs->Release cycle, and we need to have a Build->Release->Downstream Jobs pattern.
We therefore decided to create a separate job using the build step to perform the release a as a Goal. Here's the directives we are using to achieve this:
-Pdmt -Dresume=false release:clean release:prepare release:perform -DautoVersionSubmodules
A consequence of abandoning the M2 plugin for this job has been that the prompt requesting the version number is no longer appearing. Subsequently, we've been trying to achieve this via the Post-build Actions, and passing in pre-defined parameters. The issue for us here is knowing how to pass in a dynamic parameter based on the previously executed job.
An alternative angle we were looking at was specifying a properties file that the main job could tokenize prior to it's usage in the downstream jobs.
Does anyone have any advice on how we might achieve this workflow, or if it's even possible?
OK, JFTR it looks like it's outside of the scope of the maven release plugin:
To answer the question I had to enumerate some of the assumptions made by the Release
plugin. I can tell you about these baseline assumptions and you can decide whether or not > something like the Maven Release plugin is appropriate for you.
What are these assumptions?
Your codebase is going to be versioned and released as a “unit”. What
does this mean? This means that you are going to be releasing an
entire project at once with all of its submodules. [sic] In Github it means that the Maven
Release plugin is going to operate on an entire repository.
The complex relationship of the repositories, releases and resultant artifacts prevent us from automating the task in the manner described in the question
The group that I work in has standardized on Jenkins for Continuous Integration builds. Code check-in triggers a standard build, Cobertura analysis and publish to an Artifactory SNAPSHOT repo. I've just finished adding a new target to the master build file that'll kick off a Sonar run but I don't want that running on every check-in.
Is there a way to schedule a nightly build of a specific build target in Jenkins? Jenkins obviously facilitates scheduled builds but it'll run the project's regular build every time. I'd like to be able to schedule the Sonar build target to run nightly.
I could, of course, create a separate Jenkins project just to run the Sonar target on a schedule but I'm trying to avoid that if I can. Our Jenkins server already has several hundred builds on it; doubling that for the sake of scheduling nightly builds isn't very desirable. I looked for a Jenkins plug-in that might facilitate this but I couldn't find anything. Any suggestions?
Here's one way to do it, if you are ok with triggering the build using cron or some other scheduling tool:
Make the build parameterized, and use a parameter in your build file to decide if the Sonar build target should run or not.
Trigger the build remotely by HTTP POST:ing the parameter values as a form to http://[jenkins-host]/jobs/[jobname]/buildWithParameters. Depending on your Jenkins version and configuration, you might need to add an Authentication Token and include this in your url.
Authenticate your POST using a username and password.
wget --auth-no-challenge --http-user=USERNAME --http-password=PASSWORD "https://[jenkins-host]/job/[jobname]/buildWithParameters?token=<token defined in job configuration>&<param>=<value>&<param2>=<value2>"
I am also looking for a solution for this. My current solution in my mind is to create 2 triggers in the regular build, one is the nightly build, another one is Polling SCM
In the sonar plugin configuration, it has the options to skip the builds triggered by the SCM change. Therefore, only the nightly build will start a sonar analysis.
I didn't get a chance to test it now, but I suppose this will work.
Updated on 12/19/2011
The above solution doesn't work if the sonar analysis is invoked as a standalone build step. To make the sonar analysis run conditionally, you could use the following 2 plugins:
Conditional BuildStep Plugin - this allows the sonar analysis to be run conditionally
Jenkins Environment Injector Plug-in - this allows you to inject the variables to indicate how the build is triggered.
We are using TeamCity Enterprise v.9.1.1
Is there a way to trigger some action after build is complete?
I have tried adding last build step but it executed before artifacts are published.
Update: I am not looking for deployment solution. I need a way to specify generic action on build completion.
There's no generic solution at the moment.
You might want vote for the Post build task feature.
Possible workarounds include:
adding dependent build configuration (using Trigger)
creating new TeamCity plugin (e.g. custom notifier plugin, such as teamcity-slack-integration one)