Can TeamCity configuration parameters be dynamically populated? - teamcity

I'm trying to reduce input errors into my TeamCity pipelines, and would like to dynamically populate configuration parameters.
For example, ideally the allowed values of x are fetched, perhaps using a small bash function, and a drop down is generated based upon those values.
I've seen the TeamCity web parameters plug-in , but I don't have access to install plug-ins on our server.
Thanks!

Related

Ability to expose test statistics for non-maven build steps in TeamCity

Normally (when used with Maven), in order to get the number of failed/passed test we can check TestOccurrences element in Teamcity REST API.
What would be the way to report and fetch test stats for non-maven steps (e.g. custom shell script)?
Is it possible to manually set TestOccurrences somehow, so all step types would report stats in the similar way? If not, how can we make custom stats available with Teamcity REST API?

create custom build definition in VSTS using script

I am creating CI/CD pipelines in VSTS using GIT repository.
I need to use the same steps from UI while creating build definition and release configuration for projects so i want to get off this repeating manual steps and create some automation around it so I don't have to do the same steps every time.
Can anyone tell me how it is possible using scripts or any other things?
To create build definitions you have two options:
Use the new YAML builds, which allows you to specify the whole build in a YAML file instead of UI elements.
Use the Build Definition REST API create the definition locally in json form and submit it to VSTS in a single transaction. There is a nice PowerShell library called "VSTeam" which wraps the REST API functions in powershell cmd-lets.
Another thing to look at would be the use of Task Groups, these allow you to abstract away a sequence of tasks and turn those into a single reusable task.

How can I write to a Shared Resource of Custom Values in TeamCity?

TeamCity has a feature which is called "Shared Resources". This allows you to configure a set of custom values (i.e., URLs) which can be read from by the locking builds in order to properly share data and avoid resource conflicts. However, in my situation, the custom values (i.e., environment names) are not known yet. There is a separate build which will be able to create the environments. How can I have this build "write" into the custom values of the TeamCity Shared Resources so that the dependent builds can retrieve the most up-to-date values?
Currently parameters are not supported in TeamCity. Here is the related request https://youtrack.jetbrains.com/issue/TW-39174 you can vote for.

Get parameters from multiple build to one snapshot dependent build [teamcity]

In Teamcity 9.0.1 I have several builds, which ends up on similar steps, but with different parameters.
In fact, those are servicing steps, not needed by a build to conclude, that build is ok, but they are needed for service, so, currently, they are just running and consuming time.
What I am trying to reach - is move those steps to completely separate build, and invoke it on successful build end trigger. However, I could not figure out - how to pass changes parameters to these newly created build?
Snapshot dependency does not give me level of control I would like to have, as it requires me to define dependency parameters from specific build id, instead of reading them from build, which just ends.
Using artifact dependency by downloading .teamcity/properties/build.finish.gz!** fails with error:
Unknown archive type
and, actually, will oblige me to create additional xml parser
There's nothing built in to trigger builds with custom parameters on a finish-build trigger.
You will have to use the TeamCity REST API / HTTP endpoint to trigger the servicing build with custom parameters - you can pass them as key/value pairs using the following syntax (preferably use HTTPS of course):
http://testuser:testpassword#teamcity.jetbrains.com:8111/httpAuth/action.html?add2Queue=MyBuildConf&name=<full property name1>&value=<value1>&name=<full property name2>&value=<value2>
For further information see the docs.
Implementation-wise you should be able to do what you want in a few lines of powershell as a last step in the triggering build configs - they would have to pass the build parameters you want. If you use this in multiple build configurations I'd move this step into a common template or use a meta-runner.

Octopus Deploy; using parameters to define config file in transformations?

We're testing Octopus Deploy 2.0 (OD) to deploy web services, windows services and citrix applications.
QUICK QUESTION:
When using config transformation, can parameters be used to indicate which config file should be used for the transformations?
MORE DETAIL:
When setting up for config transformations, we would like to have files named
MyApp.DEV_US.config
MyApp.DEV_CANADA.config
MyApp.DEV_AUSTRALIA.config
and so on for TEST, STAGE and PRODUCTION
Our deployments to DEV, for example, always include deployments to all regions. So we would prefer if OD environments were DEV, TEST, STAGE and PRODUCTION. Then in each deployment, we have multiple steps that deploy to each region.
However, OD config transformations only look for OD Environments when looking for which config files to use as part of the transformation. It seems OD would require us to bring each region up to the environment level, which from our POV is not ideal and would clutter the dashboard.
Can we pass parameters into the config transformation process such that we can indicate which file to use for the transform?
I believe you can achieve what you are after with the following, but it will require multiple steps in the process.
Create a step called Deploy to Dev - US and a step called Deploy to Dev - Canada
Now define a variable called CountrySpecificConfigFiles and you can scope it to the required step (and environment etc)
In the Configuration transformations section for each Steps, choose the variable defined in the step above
You could abstract this further by naming your steps DEV_US and DEV_CANADA and define just the one variable value as Web.#{Octopus.Task.Name}.config without any scope to steps, or by removing the variable and doing it inline in the Additional Transforms field.

Resources