I use VSTS to build a project once changes are checked in from a git repository. That build gets stored in vsts storage. Now is there any way to easily access any retained build and copy it out for some other purpose? that is, say i've done 5 build versions.. all retained in the history of vsts. I need a copy of the 2nd build for something. Can i get to that build folder and copy it?
currently in one of the build steps it gets copied to an area called
$(Build.ArtifactStagingDirectory)\xxxxx.zip
how can i get a copy of that? trying to avoid having to remote into the build agent and dig up the files.
Use the Publish Build Artifacts task. That will upload it as a linked artifact to the build, which you can then download either via clicking on the "Download" link or via the VSTS REST API.
Related
We are using Build Pipeline in Azure DevOps to create a Deployment Artifact. Typical steps in such pipeline are:
Build Solution / Project
Copy dlls output into $Build.ArtifactStagingDirectory
Publish Artifact from $Build.ArtifactStagingDirectory
I just wonder if I can rely on the fact, that on start of each Build the Build.ArtifactStagingDirectory is empty. Or should I clean the folder as first step to be sure?
From my experience the folder was always empty, but I am not sure if I can rely on that. Is that something specific to Azure hosted Agent and maybe by using custom Build agents I have to do manual clean-ups of this folder? Maybe some old files from last build could remain there? I did not found this info in documentation.
Thanks.
I think that the main idea of this variable $Build.ArtifactStagingDirectory is to be a clean area so you can manage the code you're pushing from your repo. As far as I know, there is no explicit information on documentation talking that this folder is empty at every new build, but there are a few "clues":
You can see at the Microsoft's Build Variables documentation that Build.StagingDirectory is always purged before each new build, so you have a fresh start every build.
In the documentation above you have a few cases where it explicitly cites that some folders or files are not cleaned on a new build, like the Build.BinariesDirectory variable.
I've run a few build and realeases pointing to my Web App on Azure, and I never saw an unwanted file or folder that was not related to my build pipeline.
I hope that helps.
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 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.
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