How to get the checkout directory of project dependencies in TeamCity? - configuration

I am using TeamCity as build server and have a little trouble when configuring projects and their dependencies.
Eventually I want to get the checkout directory of project dependencies to configure certain build steps. For that I have the variable %teamcity.build.checkoutDir% for the checkout directory of the project itself.
However, I did not find something like %dep.<dependencyID>.teamcity.build.checkoutDir%.
Is there a way to get the checkout directory of a dependency?

You can add a parameter (say checkoutDir ) in the first build whose value is equal to %teamcity.build.checkoutDir% . You can then fetch this value in the dependent build (either through snapshot or artefact dependency)

I am using this myself and I can access my dependent Build's Checkout directory with...
%dep.<dependecyID>.teamcity.build.default.checkoutDir%
I believe this will only work with a Snapshot Dependency though

Related

Release Pipeline to Deployment Group on prem

I think what I am looking to do is fairly simple - I just can't wrap my head around it.
I've got a repo in AzDo. This repo contains configuration files for firewalls. This is how we manage changes in these configurations.
I've got a simple build pipeline that copies the relevant files and creates an artifact.
I have a release pipeline that gets the files onto the on-prem machine in my Deployment Group. The files show up in c:\azagent\r1\_work\<artifact folder>.
As part of this pipeline I am looking to copy the files from c:\azagent\r1\_work\<artifact folder> to e:\shares\<artifact name>. This is the part that I cannot figure out how to make work.
What strategy could I use to put this together? I've looked into the documentation but it seems like this is somewhat of an edge case (not deploying an app or web site, etc). Ideally, I'd love to do this in a multi-stage YAML pipeline - but from what I've read, it appears as if these do not yet support Deployment Groups. So a classic pipeline is fine for now.
You can add a copy file task(Click the plus sign(+) on the agent job and search for copy files) in your release pipeline to copy the files to a different place on your local machine.
Then you can specify the source folder(ie. $(System.DefaultWorkingDirectory)), and the contents to copy and the target folder(ie. e:\shares\). In below example all contents in $(System.DefaultWorkingDirectory)(ie. C:\agent\_work\r1\a) will be copied to folder D:\Test\New folder
Please check the prefined variables for more information about its map to the local folders.

How to include only a single folder in Bamboo build plan

I need Bamboo to build the project automatically when a file in "api" subfolder changes. When a file in any other subfolder changes the bamboo build plan shouldn't run.
Folder structure:
project
- api
- ui
- core
In the Plan Configuration repositories tab, from the "Include / exclude files" dropdown I have selected the following option
Include only changes that matches the following pattern
and I have tried the following patterns:
.*/api/.*
api/
api/*
api\/*
api/**
/api/*
but the build plan isn't running. With "Include / exclude files" dropdown set to None the build plan runs (but does so when a file changes in any other subfolder also)
I can't split the project up to different repositories.
What pattern should I use or is there any other solution for this?
Pattern that ended up working was
api/.*
It's a regular expression from the root of the checkout supposedly, although I have not used this feature. Here are some of their examples:
https://confluence.atlassian.com/display/BAMBOO052/_planRepositoryIncludeExcludeFilesExamples?_ga=2.91083610.1778956526.1502832020-118211336.1443803386
What you might try is let it checkout the whole thing without the include filter set, and don't let it delete the working directory. Look on the filesystem and verify the path from the root of the working directory. Then test your regex against the whole path relative from that working directory.

Is there a doc on how to setup the dev env for Polymer

It seems that you have to manually checkout a bunch of repos, and when I tried to run the core-tests runner.html, they reference htmls from outside the folder which is restricted by the browser
Polymer uses a notion of components. We define a component as a set of shareable resources in a folder. All of your components should be together in one master folder (I usually call it components). This way one component can reference another component by looking in ../<component-name>/.
A project will generally look something like this:
my-project/
index.html
components/ <-- could be symlink or a server redirection
platform/ <-- polyfills
polymer/ <-- polymer
core-ajax/ <-- a custom element
...
core-tests in particular, is itself a component. It lives in the components folder and runs tests on other components (by looking at ../<component-name>/ as above).
So, if your web-root in the example above is my-project, you should be able to access my-project/components/core-tests/runner.html to run those component tests.
There are multiple ways to populate the components folder. The easiest way is to use Bower (http://bower.io) with a command like bower install Polymer/core-elements.
You can also use Git checkouts, or ZIP archives. There is a nifty utility for downloading Bower packages as zip files at bowerarchiver.appspot.com. E.g.:
http://bowerarchiver.appspot.com/archive?core-elements=Polymer/core-elements
Will get you a zip of the core-elements Polymer component, with all of it's dependencies.
There are two Yeoman generators that can help you with starting off: yo polymer and yo element
yo polymer is based on the polymer seed-element and yo element is based on the polymer-boilerplate.
I ended up writing a blog post on getting the hang of these different setups. If you get the latest version of the generator from the github repo it will scaffold an app for you:
npm install -g git+https://github.com/yeoman/generator-polymer.git
Also make sure to have a look at the vulcanize task to concat your components.

Jenkins build promotion: How do I get the build id of the build I want to promote?

It seems that, when doing a build promotion in Jenkins using the Promoted Builds Plugin, it generates a new BUILD_ID environment variable. Is there a way, or a plugin that lets you access the current BUILD_ID of the build you are trying to promote?
Basically, the functionality I need is to: Navigate to a build in Jenkins, be able to launch an ant or gradle script to promote an already built artifact that is archived under the build I'm currently in.
Use the PROMOTED_JOB_NAME and PROMOTED_NUMBER variables to get the name and build number of the build being promoted. These two values are only set DURING the promotion process; they are part of the jobs build. This doesn't exactly map to BUILD_ID, but it does allow access to that build.
When I had this problem in the past, I did the following.
Have the original job copy certain variables (like JOB_ID) out to config style file (each line is NAME=VALUE).
Archive that file as part of the build.
At the time of the promotion, use the PROMOTED_JOB_NAME and PROMOTED_NUMBER variables to get the original build, feed the values into the Copy Artifact Plugin to retrieve the archived file of values, then use the EnvInject Plugin with that values file to bring the values into the promotion process.

SSIS Deployment: Dev Stage Live AppSettings

The main problem is: How do i incorporate an appSettings.Config file with a particular build(dev, stage, live)? My appSettings.Config changes the conx strings for data sources based on which server the package is being deployed to. I am able to go through Package configurations and add my appSettings.Config, however, I can only specifically add one file dev, stage, or live. What i need to do is be able to build the solution and based on teh build type incorporate the dev/stage/live appsettings. How could I do this?
You could include all of the configuration files in the install and then just point to the correct one through an environment variable. I know you're wanting to switch the configuration file based on the solution build configuration, but you'll be looking at a complex solution when a simpler alternative exists.
Its quite straight-forward to add registry information during the package install that will set the machine's environment variable under the key:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\MyVariable
...to the path of the .dtsConfig for the current environment.