This happens almost every now and then with the developers who are very new to the Git. I’m writing it down in the hope that if somehow the original post on stackoverflow is not available for one or other reasons, people can still find the solution. Also, even after fixing this for multiple times, I do not remember the exact commands, I still end up googling the solution. Sometimes, it takes a lot of time to find the original post as there are so many reasons for .gitignore file not working in intended ways. So the scenario is like this, that you are very new to Git or have some understanding of Git or you are very excited about an idea, you started coding on it, then you initialize and then commit your files. Continue reading “Fixing error with .gitignore file not ignoring files”
Using SonarQube extesions from Marketplace for Azure DevOps provides much of the integration functionality between Azure DevOps and SonarQube. Once the build pipeline completes, you can login in SonarQube server and view the code analysis results. Based on the code analysis results against the Quality threshold set or default Quality Gate threshold, it will be assigned a rating. However, there is no way to stop check-in of code, if it fails to passes the Quality Gate criteria. However, we can use some PowerShell and SonarQube Web APIs to do this part for us. In this blog post, we’ll learn steps to do the same. Continue reading “Fail Azure DevOps pipeline if build fail to pass the SonarQube Quality Gate”
After upgrading our SonarQube Community version to the newly released version, our build pipelines hosted in the Azure DevOps (formerly VSTS) started failing with below errors:
“02:14:02.317 ERROR: Caused by: Validation of project reactor failed:
o To use the property “sonar.branch.name”, the branch plugin is required but not installed. See the documentation of branch support: https://redirect.sonarsource.com/doc/branches.html”
We were using the same release branches that we were using earlier and there was no changes made to the build configuration. Continue reading “Azure DevOps build pipelines fails with error: To use the property “sonar.branch.name”, the branch plugin is required but not installed.”
Sometimes it happens that for the organization and maintenance purpose, you would like to keep all code related to one component of a product in one place only. Now that component may be complex component having multiple sub parts like API, UI, Database etc. Again, for the purpose of easy maintenance, you would like it all under one repository, which is not an bad idea. Now, imagine if you have different builds configured for different sub-components which are using this source code as their base and are configured to trigger on some event, say commit. Then for each small and big commit, it will trigger build in each of the configured builds. Ideally, if the change was related to only one sub-component say API, then you would need to trigger only API specific build and not the ones for the UI and/or Database. Continue reading “Using Path filters in Build definition in Azure DevOps / VSTS”
After making some changes to the build definition of one of the dotnet core repositories, we started observing this error with the SonarQube tasks inside the build definition in VSTS:
When we checked the complete logs, we observed below issue:
In git workflow, the ideal strategy to work is to fork a new branch, make changes and finally merge in the main development branches. Over the time, this results in creation of large number of branches which are not required and becomes stale. Although a branch is just a pointer to an commit and does not require more than 40 bytes of disk space, it can be painful to search a long list of branches and deciding what you want to work on. Also since we humans are not good with creating unique names for branches, they can also result in confusion.
Below are some steps to clean branches from git repository to remove the clutter. Continue reading “Delete Branches in Git using commands”
Git Cherry-pick is used by many Organizations as an alternative to the rebase and merge. Cherry-pick is used to copy selective commits from one branch to another branch. Unlike a merge or rebase, cherry-pick only brings the changes from the commits you select, instead of all the changes in a branch. You can also choose whether to apply only one commit from another branch or a number of commits from another branch.
Why Git Cherry-pick
Cherry-pick is a great way to tackle below common problems:
- Accidentally committing on the wrong branch. In this case, one can use git Cherry-pick to apply the change(s) over to the correct branch and then reset the original branch to the previous commit. Continue reading “Understanding Git Cherry-pick and how it is useful”