Aim: Set up an ant/cmd script that will package the artifacts from several builds into a single zip. I plan to do this by setting up a final build configuration that will have a dependency on those several projects.
So all my build configurations build successfully and produce build artifacts on the Build Server #.BuildServer\system\artifacts{PROJECT}{several configurations}.. In my "Artifact Aggregating" configuration, I need to be able to reference what and where those artifacts are using variables that can be used in my ant/cmd script. i.e. I have Project A with configurations w, x, and y; how would I define/construct I variables of these configurations(w,x,y) that can be referenced by build configuration z. I looked at current Teamcity documentation i.e. http://www.jetbrains.net/confluence/display/TCD3/System+Properties+of+a+Build+Configuration#SystemPropertiesofaBuildConfiguration-ref; but I find this doesn't resolve my query.
Is there a way I can set up my artifact paths for configurations w, x and y to make the final task easier?
What would be the best way to accomplish this task? Any ideas are welcome.
This is how we do that.
Create n+1 Configuration(ZIP_ALL) and add dependency for all n projects see Dependency trigger
Create network share \\server\Build for aggregating project's building results
(you need cleanup strategy for that folder) - we simply drop all, our teammates create sub folders with SVN rev name (TC sets variable with revision value)
For each configuration create msbuild(or ant, or rake) script, that will build and zip (if you need) all output from build
Copy zip file or complete Output folder to common location (\\server\Build) see Copy Task
Create ant script for ZIP_ALL configuration that simply zips all files in common location
Publish that to TeamCity via Artifact Publishing
Related
We have a microservice project architecture where there is a single project repository with several folders. Each folder has files etc for a specific API. We would like to have that as a single repo but configure separate jobs in jenkins for each API folder. As such we would like to know how to use same repo for scm checkout in jenkins but trigger builds for commits made only to the folders where changes are made. i know it supports regex to include and exclude. But would like to know how best to use that.
So say for example i have a project sample-project with 3 folders abc, def and xyz.
we now have a job in jenkins that checkouts sample-project. Now we would like that jenkins job to be configured in a way that only when anything inside abc folder is changed or committed, it triggers that job otherwise not. How to best implement this.
I have a single Cloud Source Repository with multiple projects. I am able to create a cloudbuild.yaml file in the repo root that builds all projects. However, I don't want to have a build trigger that rebuilds all of the projects since most commits will be for a single project. Ideally I would like to have a cloudbuild.yaml file in each project subdirectory and a build trigger that detects changes in the project subdirectory of the repository. Is something like this possible?
As a possible workaround, I believe I may be able to keep my cloudbuild.yaml in the repository root and create a custom step that will get the commit sha (via the COMMIT_SHA substitution) and then get the list of files committed (via "git show --name-only --pretty=format: $COMMIT_SHA") to determine which project should be built and what image should be created. An alternative may be to have a tagging naming convention that will contain the project name and basing the trigger on that but I don't want to tag each commit.
Note, it seems like build triggers work very well when you have multiple repos but we made the decision to go with a mono repo and I don't want to rehash that debate in this question. I'd like to understand how to best use the Build Triggers in a mono repo.
Im trying to figure out how to chain multiple 'promotions' (by a user clicking) whilst ensuring that ever build in the chain is not queued. By current setup is as follows, NOTE as my application is a white label the configuration described below is repeated for every site.
Build & Test - Creates zipped artifact
Deploy to Testing - Has artifact and snapshot dependency
Deploy to Staging - Has artifact and snapshot dependency
Deploy to Production Has artifact dependency
When promoting to production i want to do this across all websites (without having to manually click promote on each build).
I am currently trying the following strategy, to set the 'deploy to production' build to have a Artifact dependency, without a snapshot dependency so it doesn't queue down the chain. I have set the artifact to depend on the 'Build & Test' configuration to gain access to the zipped project and i have set it to build with a specific build number referencing a parameter in the production build.
After doing some googleing i found out that i am able to get the stagings build number using the rest api as follows:
http://teamcity_url/httpAuth/app/rest/builds/buildType:build_configuration_id/resulting-properties/build.number
And this works great, however i don't understand how i can get this value into the parameter?
Also i dont know if my approach is correct? is there a better way?
Set up the artifact dependencies chronologically (Build -> Test -> Staging -> Production) and all your snapshot dependencies to Build & Test. Depending on exact needs you might have a snapshot dependency on both Build and the one your artifact dependency is on.
Also make sure you enable "Do not run new build if there is a suitable one. This should keep it from queuing down the chain without intention.
Using the build chain tab will be important because the main project page only shows the last build ran. So clicking run from there will que the chain because you are asking for a new build, even though to you it might feel like your asking for the next step to be ran. The build chain tab helps keep things clear.
I'm trying to set up a build definition in TFS 2010. The options for this seem very limited, for instance I have 5 solution files in my source control and I don't seem to be able to specifiy which one to use. I've selected a workspace from my deployment server (which does a TF get every 10 minutes so I know it's a valid workspace), but when the build runs it gives me an error complaining about the mapping - and it seems to have made it's own mapping up from somewhere.
Mapping I set: $/InteractV4/Dev/IV4ProductionSR/
Error: There is no working folder mapping for $/InteractV4/Dev/IV4Support/iv4ProductionSR.sln.
There are 2 issues with this error. 1: it's not the workspace I was trying to use. 2: It's wrong and there is a working folder mapping for this source, both on my local PC and on the deployment pc, but NOT on the build server. Do I need to set up a load of folders and mappings on the build agent server? Or on the main TFS (source) server?
Thanks.
TFS-Builds operate on private Workspaces that get generated during the build process, so using a custom-Workspace is without tweaking impossible.It's possible to keep TFS from regenerating a new Workspace with each Buid, by going to Build Definition edit "Process":"2.Basic":"Clean Workspace" and changing default value All into either Outputs or None.The mappings are set for each Build Defition where various pairs exist:
Source Control Folder | Build Agent Folder
$/foo/bar | $(SourceDir)\somewhere
The $(SourceDir) is substituted during Build and it gets its value from the Build Agent Settings. If you go to the TFS Admin Console & select "Build Configuration", you 'll be presented with a list of Build Agents running on the Server (there might be additional Agents in other Servers). Clicking on "Properties" of an Agent, pops up a Window like that: This entry "Working directory" is the one that resolves & substitutes $(SourceDir) during build.For example, an entry $(SystemDrive)\Builds\$(BuildAgentId) could resolve into something like C:\Builds\88.So, for a TFS Build running on this Agent, you should expect all Sources that stand in source control under $/foo/bar to be found under C:\Builds\88\somewhere
EDITAccording to your comments you have now a mapping like this:
$\InteractV4\Dev\IV4ProductionSR | $(SourceDir)
Your build fails, as "There is no working folder mapping for $/InteractV4/Dev/IV4Support/iv4ProductionSR.sln".
Is this source control directory $/InteractV4/Dev/IV4Support mapped in your Build Definition?
I am trying to get over with my base structure to manage adopting alm practices.
First I have done structuring for my source folder structure where under my main branch I did put folder as builds. I was intending to store my builds (ci, nigthly, manual) be stored under each branch. However while I was creating a new build definition I stuck with a field.
Build agent folder under workspace definition should I leave it as it is $SourceDir my source control and build server are reside on same machine.
Drop folder is not the same this as builds folder in my source control, right? I mean should I keep the new builds under source control or ci server will handle it itself?
Thanks.
There's no benefit to storing your build output in version control but if your process dictates this there's nothing stopping you from doing it. You'd need to customize the build process template to achieve this as part of the automated build. Out of the box each build will create a label of the source (accessible against several workitem types) and assuming everything is setup correctly you can pull a copy of this build from the drop location on the build server.
The build server will have it's own workspace definition for which $SourceDir will map to the top level directory where the source will be pulled from version control. The Drop folder is where the final build output will be placed. It can be any local or UNC file share accessible to the account under which the builds are running.
Drop folder isn't related to yours or the build servers local workspace folder so even if you set this as the drop folder it won't get added to version control. Remember that your local workspace just provides a level of abstraction over the physical structure of your version control structure on the server. Simply mapping them one to one locally won't in anyway cause artifacts added to the local to be automatically added to the server.
Hope that makes sense.