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}}
Related
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.
We have a project on Snap CI but since it's going away we have to switch to another tool.
GoCD is our favorite but there is an important feature I am wondering if it's supported: Branch tracking.
Snap CI supports branch tracking which is currently enabled in our project: 'This repository has automatic branch tracking enabled for all branches starting with ***':
I tried to set up GoCD to do exactly this. But I couldn't find a way to achieve this behavior. The only thing I found was the feature branch / pull request plugin.
Do you know if such a feature is supported or how I have to configure the FB/PR plugin?
Thanks!
We wanted to do something similar and were faced with the same problem. In the end, we couldn't get direct branch tracking, but created a GoCD API client that created pipelines from a template, and the branch of Git material is set to a parameter (e.g. #branch). The client gets run manually when branches are created, but it could quite easily be adapted to run from hooks to automate it.
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.
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