I'd like to use the build ID in a step in Cloud Build.
I'm looking at variables available at https://cloud.google.com/build/docs/configuring-builds/substitute-variable-values but I'm not seeing anything other than $BUILD_ID that I can use but that takes up 36 characters.
Is there a short version I'm missing? There's a SHORT_SHA for the Git SHA for each commit. So I thought there might be one for the build ID.
Related
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.
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 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).
I've got a CI build pulling feature branches from Github and building/packaging them into a local folder, using a folder naming convention based on the project, branch and build number.
For named branches (feature1, feature2) this is working great.
The problem is that when I do a commit to the master, TeamCity exposes teamcity.build.branch as <default> - which means when the build step expands
E:\Packages\MyProject\%teamcity.build.branch%\
it's ending up with E:\Packages\MyProject\<default> - which is then crashing the build step because it isn't a valid Windows path.
I can see the master branch name in the fully-qualified build parameter:
teamcity.build.branch <default>
teamcity.build.checkoutDir C:\TeamCity\BuildAgents\agent-mulder\work\2151838a7933464d
teamcity.build.default.checkoutDir 2151838a7933464d
teamcity.build.id 16347
teamcity.build.vcs.branch.github_myproject refs/heads/master
but ideally I need to get master as the teamcity.build.branch for use in my build steps.
Can I transform the parameter at runtime? Override the behaviour? I've even tried setting the VCS branch name to DO_NOT_USE in the hope that "master" would no longer match the default - but this doesn't appear to work either.
In teamcity 7 its simply %vcsroot.branch%
that returns develop.
In my case I have
%MajorVersion%.%MinorVersion%.%PatchVersion%-%vcsroot.branch%
Which are all set in build parameters.
The number format is %BuildFormatSemVer% which is the stuff above and . {0}
%BuildFormatSemVer%.{0}
Which returns
#1.0.0-develop.4
Not ideal, but I was able to work around it by creating a new branch in git named "teamcity" and setting that as the default branch in TeamCity, it seems to require that the branch actually exist, since it worked when I created the branch, but didn't when you just entered a fake name.
Hopefully they actually fix this, because this is definitely a hack.
We have run into this problem several times when creating pipelines. It is the most visible when trying to automatically build feature and release branches using the Gitflow workflow. What we've been able to do was to use teamcity.build.vcs.branch.github_myproject and a regular expression in sed to sanitize the string whenever we wish to use it. This is mainly to watermark artifacts for debugging purposes.
The larger issue, at least for us, is that the TeamCity 7.1.1 version does not automatically fire off dependency builds for anything that isn't the default build in the VCS root. Obviously this is a huge pain point as we're now going to have to click manually in the tool. We haven't yet figured out a clean way to get around this other than hooks in git which use the HTTP API to call out to the proper build step.
I don't know if this was previously answered, or is any longer relevant.
In TeamCity 10.0.2 create a custom parameter such as %Git.Reference%. If you require a pull (or push) from TC to git, set this to "ref/head/Dev" or "ref/Head/yourbranch". Use this in your 'VCS root' reference.
We've just started to use TeamCity as a continuous integration server. There's a problem we're trying to solve now:
We have a 'release' configuration, it has build versions set like this: 1.0.0.{0}
We also have a 'nightly build' configuration, which build number is: 1.0.0.0.{build.vcs.number.1}
So the first 2 digits are OK, Major+Minor versions. Third one is supposed to be set up manually as well according to our process (rarely though).
But as you can see, the last one increases with every 'release'.
The question is - how do I make TC copy the current 4th digit (or all of them) of 'release' to that of 'nightly build'?
One way to do it in 4.5 is to
Make nightly have a snap shot dependency on release.
find the internal build id of release.
use a build number format in nightly that looks like
%dep.releaseid.system.build.number%.{build.vcs.number.1}
where releaseid is the id you found in step 2. This will replace the whole %...% thing with the build number from release.
The TeamCity 4.5 Docs for dependency properties explains this and shows you how to find the internal id.
If you can know it in your build script, you can send it to team city during the build. Here are the instructions. I can think of a couple of strategies for getting the build number from the release build, none of them elegant. The most obvious would be to publish an artifact from the release build that is basically a text file with the build number in it, and retrieve that from your build script.