I'm dumb with continuous integration and noticed a behavior that does not seem right..
I'm using Mercurial with TeamCity. When I push changes the TeamCity detect the changes but don't run the build automatically. This is correct behavior? He should not detect the changes and run the build automatically?
Triggers are not added to build configurations by default in TeamCity. You'll need to go to the settings for the configuration and click on "Build Triggers" then "Add Trigger". The type of trigger I believe you are looking for is a "VCS Trigger".
The documentation for this feature can be found here.
I believe my issues was misunderstanding what was needed in Branch Filters. I thought I was supposed to enter the GIT refs I wanted to have builds triggered from
This wasn't working for me
+:refs/heads/*
-:refs/heads/releases/6.7.3
-:refs/heads/releases/6.8.30
-:refs/heads/releases/6.8.32
-:refs/heads/releases/6.8.34
And this is what finally figured out (I think) is that it is asking for the branch names inside TeamCity itself (the help text says "Newline-delimited set of rules in the form of +|-:logical branch name")
This worked for me, to trigger builds from the branch (GIT ref refs/heads/master for me, look back in your VCS Root setup) and all other branches except those labeled "releases/6.7.3", "releases/6.8.30", "releases/6.8.32" and "releases/6.8.34"
+:*
-:releases/6.7.3
-:releases/6.8.30
-:releases/6.8.32
-:releases/6.8.34
Related
SonarQube has the concept of a main branch irrespective of its actual name. According to the documentation, the key is not to pass the sonar.branch.name property to the analysis.
So far, so good. However, when my Gradle build in Github does not set the property, then automatic branch detection kicks in and I get:
Detected branch/PR in 'GitHub Action'
Auto-configuring branch 'develop'
Well, that’s unfortunate, because now sonar.branch.name is set to develop, and SonarQube will not accept it as the main branch. This develop is set as the default branch in Github, but the scanner seems not able to detect this. Automatic detection will not happen when I set the property explicitly, but then of course it is still set to something.
The question is now: Can I skip branch detection in the Sonarscanner without setting sonar.branch.name? Can I influence the branch detection so it will correctly detect it is on the default branch?
We are using Github actions in a GitHub Enterprise Server 3.5.5, for reference.
I have an answer that feels more like a work-around, but seems to work. Within SonarQube, I can rename the main branch. This is more than just a cosmetic change. I set the value to develop, and the next SonarQube analysis with sonar.branch.name=develop was accepted as the main branch. This works – for now – but does not seem to be the documented and preferred way.
well i faced the same issue, while doing CICD with github action.
i use, this code to get the current branch
property "sonar.branch.name", System.getenv("BRANCH")
currentBranch is variable set in github actions
env:
BRANCH: ${{github.event.pull_request.head.ref}}
Context
I have a project absed on a vcs root with the wildcard branch filter (+:*), meaning that it will trigger a build on every possible modification pushed to git.
Because we're on a migration process, our current projects have a lot of branches, and we want to start the build process on some of them.
Issue
Because the Run button of the build starts a build with default branch (AKA master), we can't run a build on a given branch, the need being to have a select box with existing branches that you can select for the build.
Already tried / Invalid solutions
A solution would be to push a dummy commit on each branch to trigger TC and make it see the branch, this way we could select the branch in the run options, but that's not a solution to us because pushing a dummy commit just for that feels wrong.
I can also use the solution provided in Select Git branch for TeamCity Build, but the issue is that we have a lot of branches with quite heavy names, and this solution allows typo, which is not what we want.
Make sure you have correctly configured branch specification in VCS Root settings. In my case:
Go to build configuration, select branch you want to build from and press run:
Working with feature branches from TC docs should be helpful as well.
Hope that helps.
PS: Based on TC 2017.2.1 (build 50732)
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.
What I want to do:
I want to set up Continuous Integration with Team City for a project that's hosted on GitHub.
What's Currently Working
I'm properly connected to GitHub. Commits, pushing, etc etc all seem to be fine.
TeamCity is set up and I can kick off a build which will run and run my unit tests, but...
What's Not Working
When I do a TeamCity build, it looks like it's pulling down code from GitHub before doing the build or running unit tests. I want to trigger a TC build when I do a commit, before it does the push to GitHub. I don't really want it to pull any code out of GitHub before running the TC build. This doesn't seem to be working at all.
I've set up a BuildTrigger which is a VCS Trigger. I've checked the box that says Trigger a Build on Each Check-in. I added a rule to the BuildTrigger with the VCS (Github) source and my username.
When I do a commit, I don't notice TC doing anything. When I then push the commit to GitHub, TC doesn't do anything either. I see no builds queuing or anything like that.
Any clues on what I'm doing incorrectly?
Thanks!
Have you looked at TeamCity's pre-tested commit feature? It doesn't work exactly as you described you would like your workflow to operate, but it might be useful. I've used it with Subversion in the past and it works pretty well, I haven't used it with Git but JetBrains state it also works with Git.
However, the most common workflow for Git is to create feature/bugfix branches for everything you do, which allows you to commit and push freely, and merge to master when you are ready. GitHub makes the merge (and optional code review) step painless and TeamCity has built-in support to automatically build branches, see the TeamCity documentation on feature branches for specific details it provides.
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.