I know that in Build tasks you can get the commit message using $(Build.SourceVersionMessage), but what if you wanna get the same message from a Release task ?
Or how can I pass a that value as variable to the release pipeline ? thank you so much !
You can retrieve it using the REST API. You have the build ID, so you can easily make a REST API call to retrieve the commit message of the commit for that build.
However, let me leave you with some food for thought. I have no idea what you're doing with the commit message, so the following may not be relevant, but in case it is...
What if there are multiple commits between builds? You'll only get the latest commit message, not the commit messages for the commits that weren't built.
What if there are multiple builds between releases?
What if there are multiple releases, but most builds don't go to every environment? E.g. Environment 2 is 10 builds behind Environment 1.
If there is anything less than a 1 to 1 relationship between commit, builds, releases, and releases to every environment in the pipeline of that release, you are going to end up missing commit messages. Probably most of them, especially in higher environments in your release pipeline (even if every build is deployed to the first environment in your pipeline, most builds will probably not be promoted to the last environment in your pipeline).
Have a look at Variable (de|re)Hydration Tasks by Martin Hinshelwood.
These tasks basically allow you to export a subset of variables to a JSON file in a build, publish it as an artifact and import the variables again from the JSON in your release. I use these tasks often in combination with GitVersion to get detailed version information from my builds to my releases.
You can add an agentless phase
and add a Invoke REST API Task.
Another idea could be that you get the message with $(Build.SourceVersionMessage) and make it available to a release process as an artifact for example written in plain text file created during the build and published with the Publish artifact Task.
Related
I'm trying to setup a pipeline for running all kinds of tests against pull requests into my repository. Repository is git repo hosted with Bitbucket Server and TeamCity is Enterprise 2019.1.5 (build 66605). There are a few key aspects to the task:
There's a lot of tests. One way or the other tests should run in parallel to achieve reasonable execution time. The tests are already partitioned as separate TeamCity build configurations, each having good enough execution time.
There's much less build agents available for the task, so it's not impossible for a particular build to spend quite some time (up to 1-2 hours) in a build queue.
The result of the testing should be reported to Bitbucket as a single aggregate value. I.e. if there are, say, 3 individual builds from p.1 with two passing and one failing then Bitbucket should receive single "failed" build status.
Ideally, pipeline should be triggered by a feature branch change (refs/pull-requests/123/from in Bitbucket lingo), but checkout merges of the feature branch into target branch (refs/pull-requests/123/merge in Bitbucket lingo).
Given above requirements, I experimented with Composite Build Configuration (https://www.jetbrains.com/help/teamcity/composite-build-configuration.html) as it seemed perfect fit for the job. So I set up single composite build with proper builds from p.1 as snapshot dependencies, "Pull Requests" and "Commit status publisher" build features. It works perfectly, except for one thing...
The only thing I cannot seem to be able to work around is the fact that VCS roots in the dependencies collect changes when the build chain is added to the build queue. This means that because of p.2 (non-negligible max time spent in build queue) some builds end up running against a little bit dated sources. Ideally, I would like to be able to run the builds against the latest sources.
So my question is if there's any way to disable revision synchronization for dependencies? Or maybe I could approach the whole problem in some completely different way without using snapshot dependencies?
Cross-posted at community forum: https://teamcity-support.jetbrains.com/hc/en-us/community/posts/360006745840
I'm using TeamCity 2017.1.4 along with GitVersion.
The teamcity project itself consists of many build configurations the first of which is to run GitVersion and then all subsequent steps take a snapshot dependency on this step and pull the version from its parameters.
In most scenarios this works great, however if we create a new branch eg. /release-foo and push this, teamcity will not trigger a build because its already previously built the commit sha, unfortunately we need it to trigger again as even though the commit hasn't changed being in a new branch means it will get a different GitVersion number.
I've tried forcing the snapshot dependencies on the GitVersion build configuration to always be rebuilt but this seems kind of ugly as kind of breaks all other scenarios where this isn't a problem. I also know I could manually trigger the build telling it to rebuild all dependencies and it would work, however I'm curious if there's a nicer way to get teamcity to automatically trigger a build for a commit on a branch if that branch didn't previously exist, or indeed any other way I could approach this.
You could try configuring TeamCity to include different/more GitVersion version variables in the build, including the branch name and possibly version tags. This would provide a way for your build process to differentiate between the same commit on different branches.
See steps 1-5 of this CD post, as well as this detailed blog post on using GitVersionTask for some examples on how to use the additional info in TeamCity.
You can achieve this by triggering the build from a git hook.
As explained here, you can use a the update hook to identify pushed branches (even when several are pushed in a single operation) and for each branch (assuming it passes your triggering rules) trigger a TeamCity build using the REST API.
If you simply amend the commit on the new branch without modifying anything, it will get a new hash because of timestamp changes. I wouldn't consider this a nice solution, but imho it's better than triggering manually.
I have five TeamCity builds that are triggered to run at 01:00. Since they all run on the same Agent, in effect they are queued to run one after the other. Each build takes between 10-60 minutes to complete.
What I'd like to guarantee is that all five builds are run on the same revision. Currently this is not guaranteed because in case a contributing developer can't fall asleep and decides to commit something at 01:30, all builds that start running after that time will run on a different revision.
My question:
Is it possible to configure a build to use a specific VCS revision from a specific time? E.g., configure a build to use the "latest revision at the time of 01:00 today"?
Any other suggestions on how to deal with this problem would be highly appreciated as well.
One of the builds might be set up to have the others as snapshot dependencies. When that build is triggered (e.g. by schedule trigger), its dependencies will be triggered having VCS revision fixed.
Or even new build configuration might be added, it will do nothing except to triggering its snapshot dependencies (your existing configurations).
You can use independent build(or one of a builds will be a master) configuration with trigger at time you need. New config will starts other configs by PS script which calling REST API "Triggering a Build". You can point specified change for all builds(can be get with API "Get pending changes for a build configuration"). This will guarantee all builds will start with same revision. This way might help if dependencies are unacceptable.
I am thinking about a deployment pipeline using SVN, Jenkins and Maven. At the moment I'm stuck at the point where I usually would call mvn release:perform on a working copy.
When thinking in deployment pipelines, I want to create a pipeline where every commit could be used to release a software to test/production. Let's say I have 5 builds, and I decide to release build 3 (with revision 3) to production. There will already be 2 new commits to trunk (which is now at revision 5).
Is it possible to use the maven-release-plugin to checkout/build/tag/commit a release at revision 3? When the maven-release-plugin finishes the release it usually commits the modified POMs to trunk.
I'm happy about any kind of information or advice here, so feel free to point me to books (like http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912), blog posts, Jenkins documentation... Maybe I'm completely on the wrong track.
By default, the release plugin creates the release based on the contents of your working copy, it just ensures that you don't have any uncommitted content before doing so. AFAIK it doesn't force an update of the sources, as that's usually the job of the Continuous Integration system (Jenkins in your case). So whatever is checked out by Jenkins will be released.
What you're trying to do sounds more like a configuration change on the Jenkins side, pointing it to the right revision.
On the other hand, if the POM files are modified as part of the release, but have been changed in SVN in the meantime, you will run into a conflict when Maven wants to check in the modified POM files. That's a situation that might happen, depending on how for back you want to go with the release.
Based on this, it might make more sense to always create a branch before doing a release. So you would create a branch based on revision 3 and then create your release in that branch. This way, you wouldn't run into issues with committing resources that have changed in more recent revisions.
Creating the branch and checking it out could probably be automated through Jenkins and Maven as well.
As far as I tested it, it is not possible.
More explicitely, as nwinler said, when you release, maven try to commit the modified pom. But, if it's an older revision than the current one, SVN will complain that your sources are not up to date. So it won't work. ... as far as I know.
You may read docs about promotion build. I don't find any one clear enough to be pointed out (in th few minutes of the writing of this message).
Is there a way to configure Hudson to only execute Build or Post Build actions if there are changes in SVN/CVS
Thank you
You can have Hudson poll the SCM for changes and only do things if it finds changes.
Poll SCM: Configure Hudson to poll changes in
SCM.
Note that this is going to be an
expensive operation for CVS, as every
polling requires Hudson to scan the
entire workspace and verify it with
the server. Consider setting up a
"push" trigger to avoid this overhead,
as described in this document
You can also add something to your SCM post-commit hooks that will fire off a Hudson build.
Trigger builds remotely (e.g., from
scripts):
Enable this option if you would like
to trigger new builds by accessing a
special predefined URL (convenient for
scripts).
One typical example for this feature
would be to trigger new build from the
source control system's hook script,
when somebody has just committed a
change into the repository, or from a
script that parses your source control
email notifications.
You'll need to provide an
authorization token in the form of a
string so that only those who know it
would be able to remotely trigger this
project's builds.
It is not as simple as looking at the revision number (as stated elsewhere) unless your build is for the entire subversion repository. Typically you have projects sharing a single subversion repository and you are building some sub-tree. The global revision number doesn't help.
'svn info [url_to_subtree]' will show the Last Changed Date. You can parse this and figure out if it is later than your last build date and trigger a new build.