I have a build configuration that uses sources from multiple repositories. Thus, changes from all those repos go to the product. But in the process I want to know which specific repos had any changes. I couldn't find anything in the build parameters. Is there any way to get this info in the build process?
Thanks,
Zura
I suspect you've probably already come to your own conclusions on this because it seems to be standard TeamCity functionality you're asking about, but here are my notes based on my brief time using TeamCity for the sake of completeness:
A build configuration can have multiple VCS roots attached to it, and by default will start probing each root for new changes every 60 seconds
Once changes are detected for one or more of the roots, the build configuration will show "Pending(n)" next to it where n is the number of changes it's found.
If you click the triangle next to the Pending message, you see details of who committed the change a comment, and a filecount.
If you click the filecount, it will popup a list of the files, and the name and revision of the VCS root it came from.
When the build is triggered, it will remember all this change detail so you can go back later and query which changes were used in each build execution, including which VCS root and revision they originated from.
So, changes from multiple VCS roots are interleaved with each other and easy to trace. You mention "build parameters" which is also useful, and logged, however it's more about the state in which the build agent itself runs in such as filesystem paths, environment variables or parameters passed specifically into the build configuration.
Related
I have this trigger in my build configuration to trigger this build only when specific files are modified (and skip another not related to production). Build is tested and deployed to production environment. Trigger works correctly.
But what I am trying to solve are pending changes. Changes committed to VCS that are not triggered for building process and remain in interface.
Q: How to get rid these pending changes?
I can run build to remove them but by running build I do a deploy to production server, and I do not want to do this. What's the point of triggers when it is not possible to get rid of pending changes and the build has to be started manually in order to get rid of them?
I think a quick explanation of the available toolkit would be beneficial:
Trigger rules vs. Checkout rules
A VCS Trigger rule is a rule that specifies which particular changes you want to actually start the build. A Pending Change is an indication of which changes were added to the scope of the entire VCS root since the last time your build was run. This would, in many cases, indicate the differences between the source code and the latest compiled artifact, as an example.
What your build currently defaults to is that all changes in the VCS are relevant to your build, and that only a (small) subset of these changes should actually trigger a new build. In other words, TeamCity is "keeping an eye on" all of the changes relevant for your build, i.e. the entire VCS root scope.
A Checkout Rule is a rule which limits the scope of the VCS root. It specifies two things: a) the subset of the VCS contents that you wish to checkout on the agent and b) the subset of the VCS contents that you wish is tracked for "Pending changes".
One option
If you want to limit the scope of the VCS for that one particular build, one option is available for you. You could for example create a checkout rule that is similar to your trigger rules, i.e. specifying that you only want to checkout and track the paths from your trigger rule, this will then only show you "Pending Changes" for changes that match these rules. The downside of this method is that you may not checkout all required files for the job, and may not notice they are missing until your piece of software is deployed to production (what if images are not in /src/main/**, or sound files - they won't be included this way, then, unless explicitly included in the checkout rule).
Another option
...is to simply ignore the "Pending changes" number and list for that one job, if you need all of the VCS content to do a deployment.
I would like to create a build configuration which compares the results of a build, with the build before it.
In the web UI, adding an artifact dependency, the only options that looks like it could do what I want, is "Get artifcacts from: Build with specified build number", but knowing what to put in the build number box is tricky! I can't do maths in there, and even if I can, our VCS is Perforce, and changelists are not always sequential due to e.g. local/shelved changelists.
I imagine this means I need to write a script to access the REST API, so I need to figure out a build locator to get the artifacts I want... but I'm not sure what the dimensions I should specify are. Is there some combination that can give me the build before a given VCS revision number? Or will I have to walk backwards using revision:<REVISION> until I find one that exists? That feels messy!
To get the last finished "normal" build (from default branch, not personal, not canceled) from the same build configuration as your build you can use URL like .../app/rest/builds/buildType:(id:%system.teamcity.buildType.id%)
(from within the build you can authenticate with %system.pin.builds.user.name%:%system.pin.builds.user.password%)
However, if you need to get the previous build regarding changes (e.g. it can be not the last one), it will be more tricky.
When a private agent build starts in VSTS, it gets assigned a directory, e.g. C:\vstsagent_work\1\s
Is there a way to set this to a different path? On other CI servers, like Jenkins, I can define a custom workspace for a job. I'm dealing with a huge monorepo and have dozens of build definitions around the same repository. It makes sense (to me anyway) to share a single directory on the build agent computer.
The benefit to me is that my builds can use pre-built components from upstream repositories, if they have already been built.
Thanks for any help
VSTS build always creates a working directory per build definition. This leaves you two options:
Create a single build definition and use conditionals on steps to skip certain steps in order to only run what is needed. This allows you to use the standard steps and may require a powershell script to figure out which steps to run and which ones to skip. Set variables from powershell using the special logging commands.
Disable the get sources step and add a step that manually fetches sources. You'll need to clean the working directory, checkout the right commit, basically replicating the actions in the get sources step manually. It may require some fidgeting to get all the behavior correctly for normal build, pull request builds etc. That way you can take full control over the location where sources are checked out.
I'd also recommend you investigate the 2017 project formats that use the new <packageReference> in the project files to fetch packages. The new system supports configuring a version range which can always fetch the latest available version of packages. It's a better long-term solution.
No, it isn’t available in VSTS build system.
You can change working directory of agent (C:\vstsagent_work) (Re-configure it and specify another working folder), but it won’t uses the same source folder for different build definitions, the folder would be 1, 2, 3 ….
I do have a project in TeamCity, that has a build configuration for the master release branch. This is compiled, every time a new version of our product is released.
In order to be able to pinpoint the introduction of errors, I do need a big retention time for some artifacts on this build configuration. As some other artifacts are rather big (full cd installation packages), my server's hard drive gets pretty full when simply upping the cleanup interval of this configuration.
Is it possible to configure two different cleanup intervals somehow? I would love to have a big retention time for the really important artifacts, while throwing the big ones away early.
I currently use TeamCity 9.0.3
Let's say for example, that my project has two artifacs:
smallupdatepack.zip (32 mb)
reallybigupdatecd.iso (700 mb)
I would like to configure TeamCity in a way that has the .iso kept for e.g. the last 10 builds, but the .zip is kept for the last 150 builds.
What I do not want, is a solution where all the .zip files are kept forever, while only the .iso files are deleted by an interval, which is all that seemed possible to me by using the build configuration's setting's artifact patterns alone.
You can specify custom cleanup rules for porjects/targets in Build History Clean-up page.
In your case, you can have a aggressive cleanup for all builds and a lenient cleanup for the Project/target for the master build
I have uploaded an example via an image below , if it helps
If you edit any of the settings, you can set individual period for artefacts. You can setup artefacts cleanup per target. However, for the same target you cannot setup different cleanup rules for multiple artefacts.
The answer by #Biswajit_86 looks like it's the only thing available for setting special clean up rules. I looked at it and it seems like the configuration specific settings should override the project settings and give you what you need, but maybe it doesn't work that way. Try it out and see if it works. If not, file a bug/suggestion with JetBrains.
The only other thing I could think of was to create a separate build configuration that only publishes the artifacts that you want to keep longer than your default rule. Give it a snapshot dependency on the configuration that creates the files and check the box to run on the same build agent. That way it doesn't need to rebuild them and can just publish what was already created. Set up a build trigger so that this new configuration runs whenever the other one finishes. Then set the clean up rules for this configuration to the longer retention setting.
I have several projects which use code from a large set of component libraries. These libraries are under source control.
The libraries repository contains all the libraries used by all my projects and contains multiple versions of multiple libraries. Each library/version pair lives in its own folder. Each of my projects identifies the specific library/version pairs it needs through the folder paths of the references in its project file.
For example $(LibraryPath)\SomeLibrary\v1.1.5
Please note that the libraries repository is only ever added to. No changes are made to stuff already in the repository. Ever.
I have been of course been able to configure my build plan to pull the libraries repository to a libraries subfolder of the working directory. So far so good. However, using the auto branch management feature of Bamboo, this setup means that the libraries repository is cloned for each and every branch in all projects.
Not funny. No, really, not funny...
What I would like to do is:
pull the libraries repository in each build plan
but pull it to a fixed location that is the same for all build plans
it doesn't have to be an absolute path
but it does need to be outside the working directory of the current build plan to avoid unnecessary duplication
Unfortunately the Checkout Directory of the Source Code Checkout configuration task in a Bamboo build plan doesn't allow me to specify either an absolute path or a relative one that goes "up" for one or more levels from the working dir. The hint text explicitly states "(Optional) Specify an alternative sub-directory to which the code will be checked out." And indeed, specifying something like ..\Library gets punished with the message "Checkout to parent directory is forbidden".
I have seen information on the "artifact sharing" feature of Bamboo. This will probably work, but it seems like overkill for what I want to achieve.
What would be the easiest and least complicated way to achieve my goal using Atlassian's Bamboo Continuous Integration?
Out-of-the-box alternatives are welcome, but please don't direct me to any products that require intimate CLI use and/or whose documentation assumes (extensive) knowledge of 'nix and/or Java setup. I am on Windows and spoiled rotten by powerful (G)UI's.
I have the same problem - with a repository weighing in at around 2GB.
I'd like to simply "git checkout myBranch" and "git clean -fxd" instead of cloning every time (which should save a lot of time and disk space). However I also like Bamboo's automatic trigger with new branches showing up.
Like the OP, I'd love to be able to put "..\SharedDirectory" in the "CheckoutDirectory" for the
"Source Code Checkout" task but it won't let me go out above the \JOB_KEY\ folder
One possible solution is: replacing the "Source Code Checkout" task with the two git commands above. That way I can specify exact when/where/how to do the checkout. I think there may be problems with the initial checkout in this case - but once that is solved, all subsequent branches would use the same shared folder, and no more pulling down 2GB every time.