I have a TeamCity environment parameter (env.Environment) that can be set to the particular environment you can run the build against i.e. UAT, DEV
During TeamCity Build triggers setup, there are no options to select the parameters you want the triggered build to run against. When I run the build manually, I get the option to select the parameters to run against but not when setting a trigger, any ideas where/how this can be set?
There are multiple workarounds to achieve it but you cannot implement this directly in the TeamCity triggers.
The environment that you have created just change the display value to "Prompt" in the specs. But I believe it will pause the build. So whenever the build gets triggered on the scheduled time then you need to select value in the prompt.
The most efficient way that I could think of is trigger the build with the help of TC rest API. In the request payload, you can send the desired parameter value as well. So whatever the condition is just handle those things in the custom script written in any programming language.
one more (not really beautiful) way - when build started by trigger, teamcity parameter teamcity.build.triggeredBy.username is equals "Schedule Trigger"
so you can check its value in first step of build in command line and then redefine needed params
if [ %teamcity.build.triggeredBy.username% == "Schedule Trigger" ]; then
echo "##teamcity[setParameter name='env.PARAM' value='VALUE']"
fi
Related
I have 2 CICD pipeline (Build A & Build B) based on the branch X. However I would like to make sure only Build A is triggered every time there is a pull request.
Yes, I can disable the pipeline from triggering changing the settings like this, however if I do that I cant manually trigger the build.
Is there a way to disable automatic trigger yet keep the option of manually triggering open?
I have 2 CICD pipeline (Build A & Build B) based on the branch X
Agree with Krzysztof Madej.
If you create pull request and the build B is automatically triggered. We could set pr: none or check the branch policy Build Validation
if PR is completed and the Build B is automatically triggered, we could set trigger: none to disable the CI Trigger.
Yes, of course you should set pr: none. Please check PR triggers here
In the same way you can control CI triggers
We're in the process of migrating to Jenkins pipeline. We use Jenkins to update the build status of our branches/PRs in Bitbucket.
One of our merge checks in Bitbucket is "Check the last commit for at least 1 successful build and no failed builds". This means that we can't merge unless there is 1 successful build of the latest commit on Jenkins, and no failed builds of the latest commit.
Sometimes, Jenkins builds fail for reasons unrelated to the code and the build is fine next time you run it. However, this means that the branch can't be merged as there has been at least one failed build.
To get around this, we were previously able to tick the box in the build status notifier plugin configuration that said "Only show latest build status". As of yet, we're unable to find any equivalent way to configure this in a Jenkinsfile. Does anyone know if it's possible, and if so how?
This question is a duplicate of Multi branch pipeline with bitbucket build status notifier plugin in jenkins, but that question was never really answered.
It seems that your use case it's covered by the Build REST API of Bitbucket, and there is even a step-by-step example of your exact case, being last build failed for external reasons, and a new build succeeds
In order to overwrite the status of an already reported build, you will need to use the same commit sha and the same key
Regarding the Bitbucket Build Status Notifier, it allows you to specify a buildKey as an optional parameter. You should make sure to specify this parameter, and that the parameter is always the same for all builds of the same job.
That way, a new build of the same last-commit will overwrite the last one, as it will be using the same sha and the same key.
See the API section of the plugin documentation for additional parameters.
Hopefully I find here someone who has experience with Hudson and its functions.
Now . I have Hudson installed this did not reveal any problems. But now I want to create a new job and that I'm developing in C / C + +.
In addition, I am working on Subversion svn where I run on the first error. Hudson did not find my svn . He says that I need an authentication . As I learned I can at Hudson authenticate but that does not work .
Maybe one of you knows how to create a project.
The things should be done in the job of Hudson.
Hudson is on my computer (local ) delete my project.
Then Hudson to access my SVN and check out the project from there.
The whole is now compiling Hudson . ( The best would be a compiler for C / C + + for Visual Studio 2008 compiler ) . The compiler then creates a * . Exe file.
Now Hudson to start the project on the basis of the *. Exe file and run the program .
Last but not least is to Hudson case of an error or if it was all right, inform the persons working on the project via email.
So that would be it what I 've hoped of Hudson. Otherwise, I take the whole not much. I know that I can do all this via a batch file . But that's not my goal. I want Hudson to automate so that I can start at midnight my builds / tests daily.
Do you think that at Hudson are my requirement too high?
For your help I would be very grateful , as I am stuck for days.
Here is a "basic" Hudson job
Create a new free-style software project job.
Configure that job.
(Optional) Configure triggers, such as "timer", "SCM polling", or others.
(Optional) Under Source Code Management section, select your SCM source and configure your repositories and local workspace
Under Build section, select Add build step and select:
Execute Shell if on *nix
OR
Execute Windows Batch Command if on Windows
OR
Pick whatever build-step plugin you are using.
(If using either of the "execute" build steps) Write your build/make/compile command as you would from command line.
(If using another plugin build step) Configure the plugin options according to your requirements.
(Optional) Archive the artifacts of the build with Archive the artifacts under Post-build Actions
(Optional) Execute other post-build actions
(Optional) Send out an email
Now to address your specific scenario. First things first, your question is too broad, and may get locked. Don't get discouraged if that happens, create separate question for each item individually. I cannot cover in details all these items, but I will give you an overview.
The SCM part
Based on your previous question, No Credentials to try in Hudson, I am now guessing that you are not providing Hudson with an HTTP URL to your SVN server, but trying to give it your local workspace location... Please do the command line check that I asked in that question.
You need to provide it with a proper HTTP server URL. Hudson will check out the project from the SVN URL you provided, under what is called a Workspace. The location of workspace can differ, based on your Hudson configuration, but it is a folder inside Hudson installation that is dedicated to the job. It can be referenced from within the job through %WORKSPACE% environment variable.
There are ways to use a different workspace location, but that is outside the scope of this overview. The whole SCM part is also optional, you can rely on existing file system, but this is not a good approach, and again, out of scope of this overview.
The Build step
After Hudson checked-out/updated the Workspace with your SVN, comes the building step. Hudson can do Execute Windows Batch Command by default. It can also Invoke Ant by default. (It can also do Maven, but that is not applicable to your situation)
To do other types of builds, you need a Build Wrapper plugin. In your particular case, the MSBuild plugin is probably what you want. I've never used MSBuild, so cannot give you details. Again, if you have a specific question on how to use MSBuild plugin, you should probably make a separate question with specific issues.
So, using either Execute Windows Batch Command or MSBuild plugin, configure your building step.
Running the exe???
This is very vague. You want to start the .exe and then what? Will it quit and you need an exit code? Do you want to see it on the screen? Again, this is very broad, and deserves a separate question (or read existing questions). If you just want to make a call to the .exe, you can configure a second Execute Windows Batch Command step, type there call path\to\yourfile.exe. But most likely you will not see that on screen. Read my answer here, Open Excel on Jenkins CI, on details of launching an .exe from Hudson/Jenkins that would be visible on screen.
Email
If you want a simple email, Hudson Post-Build actions has a way to send an email. For better customization options, you would want Email-Ext plugin. Once again, if you need details on how to use the email-ext plugin, create a new question (after searching existing questions first), as this is too much to cover in one question.
Conclusion
Your requirements are not too high, but Hudson is not a magic tool that will do the work for you. You still need to configure every step of it. And unless you have a Maven based project (which integrate very well with Hudson), a lot of actions will need to be done through the Execute Windows Batch Command and scripting of your own.
I installed the Promoted Build Plugin from Jenkins and now I'm facing some troubles to promote a build from an existing job. Here is the scenario:
There is an existing Nightly Build job that runs every night running all the tests and metrics needed;
There is an existing Deploy Build that accepts a parameter ${BUILD_NUMBER} and deploys the build that has the corresponding ${BUILD_NUMBER} from the Nightly Build
Say the [Nightly Build] ran and successfully built the artifact #39
Now I can just run the [Deploy Build] passing in #39 as a parameter
The artifacts from [Nightly Build] #39 are going to be deployed
So far so good. Now is the part where I want to add the Build Promotions...
Is there a way to promote the Nightly Build #39 (notice that it was already built before) from the Deploy Build? Or maybe even from somewhere else, quite frankly I`m kind of lost here :(
I don`t see them with a clear Upstream/Downstream relationship, because they don't have a: always runs this build and then the other during the execution - the [Deploy Build] is executed sometimes only and not always after the [Nightly Build].
Update as of version 2.23 of Parameterized Trigger Plugin:
With version 2.23+ behavior changed (thanks AbhijeetKamble for pointing out). Any parameter that is being passed by Predefined Parameters section of calling (build) job has to exist in the called (deploy) job. Furthermore, the restrictions of called job's parameters apply, so if the called job's parameter is a choice, it has to have all possible values (from promotions) pre-populated. Or just use Text parameter type.
Solution
Yes, I have the exact same setup: a build job (based on SVN commits) and manually executed deploy job. When the user selects any build from the build job (including older builds), they can then go to Promotion Status link and execute various deploy promotions, for example Deploy to DEV, Deploy to QA, etc
Here is how to setup the promotion on build job:
You will need these plugins: Parameterized Trigger Plugin, Promoted Builds Plugin
You will also need to setup default Archive the Artifacts post-build action on this build job.
Check mark Promote builds when
Define Name "Deploy to DEV"
Under Criteria check mark Only when manually approved
Under Actions use Trigger/call builds on other projects
In Projects to build enter the name to your deploy job here
Check mark Block until the triggered projects finish their builds
Mark this build as failure if the triggered build is worse or equal to: FAILURE (adjust according to statuses of your deploy job)
Predefined parameters (Code A)
Code A:
Server=IP_of_my_dev_server`
Job=$PROMOTED_JOB_NAME`
BuildSelection=<SpecificBuildSelector><buildNumber>$PROMOTED_NUMBER</buildNumber></SpecificBuildSelector>
Above, in the Predefined parameters section, the name to the left of = are the parameters that are defined in your deploy job. And to the right of = are the values that will be assigned to those parameters when this promotion executes. Defines three parameters Server, Job and BuildSelection.
The parameter Server= is my own, as my deploy job can deploy to multiple servers. However if your deploy job is hardcoded to always deploy to a specific location, you won't need that.
The Job= parameter is required, but the name of the param depends on what you've setup in your deploy job (I will explain configuration there). The value $PROMOTED_JOB_NAME has to remain as is. This is an environment variable that the promotion process is aware of and refers back to the name of your build job (the one where promotion process is configured)
The BuildSelection= parameter is required. This whole line has to remain as is. The value passed is $PROMOTED_NUMBER, which once again the promotion is aware of. In your example, it would be #39.
The Block until the triggered projects finish their builds check mark will make the promotion process wait until the deploy job finished. If not, the promotion process will trigger the deployment job and quit with success. Waiting for the deploy job to finish has the benefit that if the deploy job fails, the promotion star will be marked with failure too.
(One little note here: the promotion star will appear successful while the deploy job is running. If there is a deploy failure, it will only change to failure after the deploy job finished. Logical... but can be a bit confusing if you look at the promotion star before the deployment completed)
Here is how to setup deploy job
You will need Copy Artifacts plugin
Under This build is parameterized
Configure a parameter of type Choice (or Text) with name Server (this name has to match with configuration in promotion's Predefined Parameters in previous section)
Choices: Enter list of possible server IPs that would be used by the promotion's Predefined Parameters in previous section (see update note below)
Configure a parameter of type Choice (or Text) with name Job (this name has to match with configuration in promotion's Predefined Parameters in previous section)
Choices: Enter the name of your build job as default. This is only needed if you trigger the deploy job manually. When the deploy job is triggered from promotion, the promotion will supply the value (the Job= from Predefined parameters that we configured). Also, if there is no value passed from promotion's Predefined parameters, the first choice value will be used. If you have a 1-to-1 relationship between the build and deploy jobs, you can omit the Job= parameter in promotion's configuration.
Update: since version 2.23 of Parameterized Trigger, the available choices in the deploy job configuration have to have all possible values coming from the promotion's predefined parameters. If you don't want that limit, use "Text" instead of "Choice"
Configure a parameter of type Build selector for Copy Artifact with name: BuildSelection
Default Selector: Latest successful build
Under Build steps
Configure Copy artifacts from another project
In Project name enter ${Job}
At Which build choose Specified by a build parameter
In Parameter Name enter BuildSelection (without ${...}!)
Configure the rest accordingly for your artifacts that will be copied from build job to deploy job's workspace
Use the copied artifacts inside the deploy job as you need in order to deploy
So now, with the above deploy job, you can run it manually and select which build number from build job you want to deploy (last build, last successful, by build number, etc). You probably already have it configured very similarly. The promotion on the build job will basically execute the same thing, and supply the build number, based on what promotion was executed.
Let me know if you got any issues with the instructions.
Marked answer is great explanation for the question. But I would like to suggest a solution for those people looking for "how-to-promote-a-specific-build-number-from-another-job-in-jenkins"
We can use a generalized solution for doing force promotion using CURL and REST API. You can execute curl from Shell or Groovy scripts.
Shell Solution using CURL:
user_name="jenkins_user"
user_token="token"
promotion_name="Test_Promote"
jenkins_url="http://build-server.com"
JOB_NAME="job_name"
JOB_NO="job-no"
url="--silent -u $user_name:$user_token $jenkins_url/job/$JOB_NAME/$JOB_NO/promotion/forcePromotion?name=$promotion_name"
curl $url
Groovy Soultion:
user_name="jenkins_user"
user_token="token"
promotion_name="Test_Promote"
jenkins_url="http://build-server.com"
JOB_NAME="job_name"
JOB_NO="job-no"
def response = "curl -u $user_name:$user_token \" $jenkins_url/job/$JOB_NAME/$JOB_NO/promotion/forcePromotion?name=$promotion_name".execute().text
How to generate jenkins user token: https://jenkins.io/blog/2018/07/02/new-api-token-system/
Is it possible to trigger a Hudson/Jenkins build only when a certain string appears in a commit-message?
For instance, I want to trigger a build that rolls out my application to the dev environment by writing a commit message like:
MYPROJECT-123 Fixed NPE in MyClass.java #deploy:DEV
The general idea is described in this great talk on Continuos Deployment but I couldn't find any information on how to do this in Hudson.
I would prefer to have this behavior in Hudson itself and not in an external system like commit-hooks or web-hooks.
I don't know of an out of the box way you can parse the SCM message as part of the trigger. You have a couple of options that might achieve what you want though
Write your own Hudson SCM plugin
Chain your jobs together into a build pipeline. The first job could simply look for that message in the changelog.xml to determine if the next build is triggered or not.
If you are looking at building a pipeline of build jobs, check out the build-pipeline-plugin. http://www.centrumsystems.com.au/blog/?p=121
Anyone got a more elegant solution??
Cheers,
Geoff
There is a plugin called Commit Message Trigger Plugin, but it had just a 0.1 release.
Maybe the easiest way is to use a version control post commit (or push) trigger to start a Hudson Job. You'd one anyway to automatically start your build.