For testing purposes I sometimes copy some Jenkins jobs from a produtive instance into our testing instance.
Repositories, branches etc. are controlled by environment variables but I want to block the "Deploy artifacts to Maven repository" post build action for all jobs in this Jenkins instance.
Any idea how to do this?
There is a Jenkins plugin for conditional build steps: Conditional Build Step Plugin. While plugin supports a variety of condition types, for reference here simple use of toggling deployment via global Jenkins property used in a boolean condition.
Property can be defined as Global Property in Jenkins configuration (Jenkins home > Manage > Configure: Global Properties)
As example lets say you have defined a property with name doMavenDeploy:
production environment: property value is true
test environment: property value is false
job configuration would need to be modified to add a Conditional build step with :
Run? : Boolean condition
Token : $doMavenDeploy
Step to run if condition is met : add maven deployment there.
In that way you would need to modify your jobs once, after modified configuration is active you can move them between both servers without impacts.
There are other alternatives possible depending on specifics and constraints in your projects:
introduce different maven profiles for 'normal' and test builds and control activation via environment variable, file present or similar
if you use artifactory/nexus or similar: configure test server without deployer credentials
Related
I'm working on a Jenkins Pipeline script and ran into a case where I need to get a value that is set in the Jenkins Global Configuration. The Manage Jenkins : Configure System page is where I set a value for one of the plugins installed. The plugin provides a configuration line to add a URL (Confluence URL). I want to access the URL in my pipeline to use for a specialize step. The issue I'm having is I'm unsure how to get a global configuration defined by a plugin. Is there a way to access global configuration values from a pipeline? Or would the plugin have to expose it?
I am using the 3 build configurations to use VCS root as develop, staging and master. Each having custom parameters like build env, Kubernetes cluster, namespaces, etc.
However, sometimes my dev team needs to check if the master branch code is running correctly on dev env, dev K8s cluster, dev namespaces.
For that, I want to create the custom prompt-based parameters where they can choose the VCS Root with parameter options like develop, master or staging.
Can anyone please guide how to achieve this for the single build configuration? Can I parameterize the VCS root? I want to keep this prompt-based option so there will not be any automatic trigger required.
I will keep the the common 3 build configurations as it is. I just want to add 4th build configuration named as "Custom" where there will be choice for every parameter.
Yes, you can parameterize your VCS root,
if your repository is same for all environments then you have to set only one parameter for VCS root an that is for branch name.
Step 1 :
Write %branch-name% in VCS root configuration and save it.
The same parameter (config.branch-name) will be added automatically in your build configuration in which this VCS root used (new configuration as well as in existing configuration)
Step 2 :
In other configuration keep your config.branch-name parameter as it is ( Type : Configuration parameter, Display:Normal) but,
in new configuration, set Display : prompt for config.branch-name parameter
Note : This is only for setting variable based VCS root, assuming you can set all other parameters as per your requirement
VSTS allows you to select which branches automatically trigger a CI build by specifying a branch pattern.
However, my unit tests are using a real database which causes a problem when more than one build triggers e.g. master and feature-123 as they will clash on the database tests.
Is there a way of specifying that only one such build should be run at at time; I don't want to go away from executing tests against a real database as there are significant differences between an in-memory database and SQL Azure.
VSTS already serialize builds which are triggered by the same CI build.
Even CI build can be triggered by multiple branches, but for a certain time, only one build is running by default (unless you use pipelines to run builds concurrently).
Such as if both master branch and feature-123 branch are pushed to remote repo at the time time, the CI build definition will trriger two builds serially (not concurrently).
If you are using pipeline and need to run the triggered builds serially, you should make sure only one agent is used for the CI builds. You can use the way below:
In your CI build definition -> Options Tab -> add demands to specify which agent you want to use for the CI build.
Assume in default agent pool, there are three agents with the agent name: default1, default2 and default3.
If you need to specify default2 agent to run the CI build, then you can add the demands as below:
Now even multiple branches have been pushed at the same time, they will be triggered one by one since only one agent is available for the CI build.
If you use a YAML pipeline, you can use a deployment job in stead of a regular job.
With a deployment job you select a named Environment you want to deploy to.
You can configure the Environment in azure devops under Pipelines->Environments and you can choose to add an Exclusive Lock.
Then only one run can use the environment at a time and this serializes your runs.
Unfortunately, if you have multiple runs waiting for the environment (because one run currently has it locked), when the environment becomes unlocked only the latest run will continue. All the others waiting for the lock will be cancelled.
If you want to do it via .yml or .yaml file you can do following
- phase: Build
queue:
name: <Agent pool name>
demands:
- agent.name -equals <agent name from agent pool>
steps:
- task: <taskname>
displayName: 'some display name'
inputs:
value: '<input variable based on type of task'
variableName: '<input variable name>'
I have a sub project in which I would like to ensure the build configurations in this sub project will never run at the same time.
All the build configurations are based on the same template and I have tried setting "limit the number of concurrent build to" 1 but this has no effect. I assume since this binds to the concrete build configuration and not the template.
I assumed I could set an agent requirement to limit the name to the build agent in a snapshot dependence but apparently agent requirements will not evaluate variables.
I also have a build configuration called All which has snapshot dependencies on all the build configurations in my sub project. Under snapshot dependencies settings I tried setting "Run on same build agent" but this could result in the build queue could run on "No agents". I assume because I started one build configuration manually. Then invoked all which confused Teamcity.
The only thing that works is hardcoding the agent name as a requirement but I'm not a fan of this solution. How can I limit simultanious builds across a sub project without hardcoding an agent name.
I think what you need is Shared Resources.
From official documentation:
The Shared Resources build feature allows limiting concurrently
running builds using a shared resource, such as an external (to the CI
server) resource, e.g. test database, or a server with a limited
number of connections, etc.
I don't want Build Config A and Build Config B to run at the same time. This is because they share the same resource which cannot be accessed simultaneously. However each build config is run by a separate agent so it is possible for them to run simultaneously.
Instead I would like one build config, when triggered, to wait for the other to finish if it is running. For example if Build Config B begins to run but Build Config A is already running, then B would wait until A finishes and then B would run.
I don't think a snapshot dependency will work because that assumes one config has a dependency on the other which is not true in my case.
Keith, there are two plugins that can help you:
The first one is Groovy plugin. It has functionality of creating name locks over all projects.
The second one is TeamCity.SharedResources. It has functionality of definig shared resources and locking them with read and write locks. However, resources defined in this plugin, are are defined per-project. We are actively developing this plugin, so you are welcome to watch its page in our tracker
For a quick and dirty, just make a rule on the compatible agents tab for the project. That they have to run on the agent name containing xxx ( whatever that is ) then those builds can only run on that agent and will never run at the same time.
In the newest version of TeamCity, you can configure this parameter. Go to the Edit Configuration Settings -> Edit Configuration Settings and set parametr:
Limit the number of simultaneously running builds (0 — unlimited)