I am using Sonarqube-7.7 version. My colleague has deactivated some rules in the quality gates. But when I am importing the same rule-setup in my local and setting as Default, I can see that many rules which have been deactivated, are still activated in my machine.
Please let me know if I am missing any steps?
I want the exact rule-setup in my local that my colleague has sent so that I can pass the same to my team.
We have found out that there is no other way round (as per our knowledge) but to just manually deactivate the activated rules to generate the report.
We can define our own ruleset according to our need.
Thanks.
Related
Using TeamCity version 2017.2.3 (build 51047).
I have a SMB Upload build step and would like to upload the builds from the default branch to a different location than all other builds.
I seen the following variable that will tell me if its a deafult build %teamcity.build.branch.is_default% however im not too sure how or even if its possible to specify conditional Target URL for the SMB Upload step.
Either with some form on IF block, or ternary statement inline.
Non of this is done using PowerShell. All through the UI, i would prefer to keep it that way if possible. Our old TeamCity install saws essentially just a glorified PowerShell script runner and grew into this un maintainable monolith, besides PowerShell is a rather terrible language.
Essentially what i would like would be builds on any branch going to
//DataStore/builds/my-api-%build.number%.zip
Whilst builds on the default branch go to
//DataStore/builds/default/my-api-%build.number%.zip
Any help would be appreciated thanks.
In general, this is not possible. The SMB Upload runner doesn't let you specify a condition anywhere in it.
If conditional steps were possible, you could create two steps: Upload from default and Upload from non-default, each with a different Target URL. It turns out that conditional build steps are the most voted-for feature in TeamCity, see this ticket, yet JetBrains are quite opposed to the idea. You may want to vote for the ticket, or at least monitor it.
There is one thing that you can do, other than Powershell. The Target URL field expands variables. (You can tell this by typing a percent sign in the text field: TeamCity immediately starts suggesting variable names. Compare this with the Step name text field above: that has no variable expansion.) Thus, you could enter a Target URL in this form:
//DataStore/builds/%teamcity.build.branch.is_default%/my-api-%build.number%.zip
That way, you'll end up with files being uploaded as
//DataStore/builds/true/my-api-1234.zip
//DataStore/builds/false/my-api-1235.zip
Now that's kind-of ugly. You can improve it in two ways:
1) create symlinks or junctions on your file server (on the directory/filesystem level), so that the above are accessible to the clients as
//DataStore/builds/default/my-api-1234.zip
//DataStore/builds/my-api-1235.zip
2) even better, you can set up a variable that will either contain the value "/default" or "". Then you can change your Target URL to //DataStore/builds%myCleverVariable%/my-api-%build.number%.zip. To do that, you'll need an extra step before this one, a Powershell runner, that will test the value of %teamcity.build.branch.is_default% and set %myCleverVariable% accordingly, using TeamCity service messages.
The conditional build step feature has been implemented in TeamCity 2020.1
I have a build environment with multiple agents.
I would like to set up an Agent Requirement in my build that detects if certain software is installed. In some cases I can look in the env.Path for a particular string. But some software doesn't modify the Path.
I realize that after I install the software i could edit the BuildAgent.properties file to set a particular property, but I'd like it to be more automatic.
The specific instance is I have a build that uses MSDeploy to deploy websites, but it won't work if MSDeploy isn't installed. How can I specify in my build that I need an Agent that has MSDeploy installed?
You can build a simple agent plugin. Here are a few suggestions:
Extend AgentLifeCycleAdapter and implement agentInitialized method
Implement logic of detection the necessary application (for example based on some file existence) inside agentInitialized method
Use agent.getConfiguration().addConfigurationParameter() to report agent parameter to the server
If your detection logic can be implemented through file detection, you can use FileWatcher to monitor specific files and report parameters based on them even without restart of the agent
To my knowledge Agent Requirements work simply by validating either the existence of, or the value set in an Agent Parameter. As you say, this requires editing the <agent home>/conf/buildAgent.properties configuration file, either manually or in some automated way.
In terms of automation, you could take the approach of authoring a build configuration that acts as an agent bootstrapper; i.e. a build that runs on all agents (scheduled overnight / manually triggered) and maintains build agent parameters in the <agent home>/conf/buildAgent.properties file depending on certain conditions on the agent. Something like (pseudo):
if [ exists /path/to/MSDeploy ] then echo MSDeployExists to buildAgent.properties
This comes with a big disclaimer; I haven't tried this myself, and I believe that the agent will restart automatically based on changes to this file, so there may be issues with editing that file automatically. But it's a potential solution to maintaining your requirements in a centralised manner, and if it works then great. I use a similar approach to bootstrapping custom build scripts out to all agents to augment the already rich feature set in TeamCity.
I agree with the answer from SteveChapman. It is clear that you can test for environment variables (exits, contains, starts with, etc.). TeamCity is aware of versions of .NET installed on the agent (as well as Visual Studio, and VS SDKs). However, I can't find anything that would be equivalent to a "testpath" sort of capability.
The sure way to know is to add an agent parameter via the <agent home>/conf/buildAgent.properties configuration file.
We are going to use TFS 2010 for a new project and I'm looking for a best practice and knowledge/experience about using the policy check in option when developing as a team.
I've found information about all this but not really that much information about best practices and what dev teams opinions and experiences about policies, which they used and perhaps should have used.
Which policies did you use?
What was your experience?
What would you recommend?
For instance have you used Microsoft Minimum Recommended Rules and did you use them all?
Information and your experience is appreciated.
The most essential check-in policies are:
Comment Policy - require comments for all check ins.
Work Item association - this should be mandatory as without it you cannot group change sets to a particular stream of work. You need to be able to do this for merging and rolling back changes wholesale.
Gated Check In - While not a policy as such (you need to create a gated build) it prevents developers from checking in code that breaks the build. If you created linked builds across your code base you can ensure your solutions are never broken by check in again. I've done it and it works.
There are many others (we use a Gemini item association policy) and you can write your own as we have. It's not that hard and you can tailor them to fit.
This is more of a discussion question, which is not the type of question StackOverflow usually wants, but I'll bite.
The policies that for me make sense are:
Builds policy
This policy prevents a build queue of failed builds after someone breaks the build. You will actually be warned that the build is currently broken, so that someone can fix the build before continuing.
Work Item Association
We need work item association to ensure we can trace checkins to work being done an through that to testcases.
Work item Query
We want people to select their work from the current sprint/iteration. So it's handy to verify that the work people are checking in against is actually pre-approved work.
Custom Path Policy
We use this policy once in a while in Team projects that house more than one project and where we want to increase quality or security on one project, but are not interested in bothering the other project. Or to prevent certain checkins on the current release branch, but don't want such stringent policies on an old release that is still being maintained.
We verify a few things which you could do through checkin-policies by failing the CI build instead. This is done mostly to save time on the developers machines.
Code Analysis Policy.
Instead of using a checkin policy for this, we use a CI build which will fail if certain Code Analysis rules are broken. This allows us to let the developer builds skip Code Analysis on every build. People will learn pretty quickly how to prevent these rules from triggering anyways.
We're not using any other policy. The Require comment for change set policy is something we sometimes use, but most teams actually don't need a policy for this after some time. Having no comments on a checkin is frowned upon by most and this resolves itself.
We had a couple of projects where time tracking was done (for MSF CMMI) and we used a custom policy to ensure people updated their hours on every checkin.
We're not using any policy to enforce Code Coverage or Number of warnings. These can be added to the build if needed through build process customization.
We use Gated Checkins on branches that require additional verification. Such as release branches and branches that are followed by automatic deployment.
We often allow developers to by-pass any checkin policy without penalty. Same goes for gated Checkins. It is up to the developer to use these rights wisely. Breaking a deployment is something you cannot do too often before being noticed by the team ;).
There are a few interesting custom policies out there as well, but I know only a handful of people who actually went as far as to use these.
Merge only policy
This policy allows you to specify a couple of branches that can only receive merges of already checked in work on another branch.
Forbidden Patterns Policy
I've sometimes used these to ensure no /bin/debug, .exe or .dll was checked into a //src/ folder in TFS.
There are a few more policies from 3rd parties, but I've never used those. These include:
The Checkin Policy Pack and that page lists a couple of extra policies that I've never had to use either.
One of the reasons for not using too many 3rd party policies is that all team members need to have the polcies installed on their machines. The Team Foundation Server Power Tools can help you out with the distribution, but those are not deployed and configured on all developers workstations by default.
Also available in blog form.
Try each of the check-in policies to see if they provide value to your team.
Some of our Team Projects require only a check in comment. Some require a comment and a work item. Some require a successful build. It all depends on what the team requires.
Don't try to follow someone else's best practice. Determine what works in your environment.
I am managing a build lab and have several products/branches to provide service to and I would like my build machines not to be specialized to any one product/branch.
The scenario I would like to have is that souce and all tools needed to build it are checked into source control and just sync and build with some prep/env setup before hand via script.
This is very doable with Visual Studio and many other tools. Is it possible with Xcode? Has anyone gotten a scenario like this to work?
Some system components may need to be shared. Since this is such an atypical scenario, documentation will not be readily available. I would suggest asking on the Xcode-users mailing list that Apple maintains, as you may get a more certain answer.
I doubt if this possible. There are 2 possible ways I know of.
First, which we also follow in our project:
Source code for all projects in checked in the common repository.
A remote server is configured to point to this repository.
Remote server has XCode pre-installed. A pre-written scripts with steps including workspace cleanup, checkout fresh code, build the code, package the output is already feed into the remote server. Of these XCode related commands are using xcodebuild.
Remote server can be configured in 3 ways: a) Build the source code on every checkin, b) Build the source code triggered by user, c) Scheduled building of the source code.
Build results are emailed to the configured email addresses.
Second way is the continuous integration with MAC OS X server.
Just in case you found out the exact system config you are looking for, please post an answer here to enlighten us as well.
I'm in the process of setting up a proper CI environment and am currently evaluation TeamCity. (So my TeamCity experience is non-existent.).
I've performed a default install of TeamCity 5.0.1 Professional in a clean Windows XP (for now) VM.
I've created my project and pointed it to my source repository and queued up a build.
However, I don't see any Build Agents installed/available via the Team City web interface. I've checked and there is a 'Team City Build Agent' service installed and it's running. I've also reviewed the log files in the buildAgent folder and don't see anything that would lead me to an error.
Is there a step or concept that I'm missing here on getting the default Build Agent to become available to Team City? I'm not trying to do anything complicated with the build. (at this point, I just want to pull my source down from the repository)
I had exactly the same problem. After going through settings, reinstalling the agent etc, I found that the problem was rather simple - the TeamCity agent placed a wrong teamcity URL in it's property (and other paths as well).
Find the buildagent.properties file ( buildAgentInstallDir\conf\buildagent.properties), and you'll probably see that all of the lines have 'escape' characters in them (e.g. serverUrl=http://localhost:8090/ )
Modify the file to remove escape chars (i.e. links should be plain like: serverUrl=http://localhost:8090/ , env.TEAMCITY_JRE=C:\Program Files\TeamCity\BuildAgentInstalled\jre and similar)
Hope this helps...
If your server is running on a machine with multiple IP addresses, the agent may fail to identify the correct IP address. You can explicitly set the IP address in the buildAgent/conf/buildAgent.properties file. You should see a section that is optional to set the IP of the buildAgent and the IP of the Teamcity server. I recommend trying both.
Right after a clean install you should see one build agent - the local machine. I don't think this has anything to do with you even having to have a project defined. IMHO you something went wrong with the installation.
Filip
If you've changed the TeamCity server port in conf/server.xml like:
<Connector port="8222" protocol=".."/>
You should change the default agent configuration in buildAgent/conf/buildAgent.properties
serverUrl=http://SERVER-IP-HERE:8222/