
This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Top 3 Git Features coming in TeamForge 8.0
CollabNet just released TeamForge 8.0 and with it some significant new features for our Git/Gerrit integration. Without further ado, let’s have a look into the top three.
Define Git permissions globally: Site-wide role support for Gerrit
As described in detail in my previous blog post, TeamForge project roles control access to all tools integrated in your development process, no matter whether you use Git, Subversion or both, how many servers you use or what your favorite issue tracker is.
What happens if you like to define permissions across TeamForge projects on a global basis? Let’s say you have a group of architects that should have read access to all source code repositories on your site. In that case, you can define a TeamForge site-wide role, configure SCM permissions and assign this role to your architects.
Starting from TeamForge 8.0, our Git/Gerrit integrations supports site-wide roles, or more precisely, all SCM related permission clusters and the project admin flag. Doing that, you can easily define SCM related permissions across TeamForge projects and version control systems.
We decided that a permission cluster granted by a site-wide role should have the same meaning as if it came from a project role. For instance, if you configured the mandatory review policy for a repository and a site-wide role gave Commit/View to a user, this user would still have to follow the review process and could not push directly to a branch.
Site-wide role support is enabled for all new TeamForge 8.0 installations by default. For existing installations, you have to turn it on explicitly by setting the property
teamforge.supportSiteWideRoles
in gerrit.config to true.
Enable anonymous repository access: Support for default access permissions
Apart from project roles, TeamForge also provides a feature that can be used to control what kind of access should be possible for non-project members or even anonymous users. Default access permissions make it possible to define permissions beyond the primary stakeholders (i.e. project members).
The screenshot above shows an example where anonymous read access is granted to two repositories (rr-commitmsg and rr-test-01). Anybody with an account on the site will have read access to all repositories in the project and commit access to rr-powerexample. Default access permissions can also be used to control access to other integrated tools (like the read access for documents for non-restricted users in this example).
Starting from TeamForge 8.0, default access permissions are supported for Git/Gerrit as well. The screenshot below shows an anonymous clone URL (http only as ssh requires a user account).
Default access permission support can be turned on in gerrit.config by setting property
teamforge.supportDefaultAccessPermissions
to true (turned on by default for new installations).
Turning on this feature will replace your existing access rights for Gerrit’s Anonymous and Registered user groups on project leaf level.
Seamlessly navigate between TeamForge projects and related Gerrit reviews
If you have upgraded to TeamForge 8.0, all of your projects with a Git repository will include a new Gerrit icon on the menu bar.
If you click on this icon, you will navigate to the Gerrit dashboard showing the status of all code reviews related to the repositories of this project.
If you now decide to browse Git repository content from Gerrit’s UI, the TeamForge project context will be preserved, so you can easily navigate back to the TeamForge page, enabling a seamless navigation experience across three different apps (TeamForge -> Gerrit -> GitWeb -> TeamForge).
If you do not like the Gerrit icon in your project menu bar, you can disable the feature by setting
teamforge.createTFProjectLinkedApps
to false in gerrit.config.
Wait, there’s more …
The three features explained so far will only work if you upgrade to TeamForge 8.0. Apart from them, there have been numerous smaller features, bug fixes and performance improvements to our Git integration that apply to all TeamForge versions starting from TeamForge 7.1. If you are interested in the details, check out our release notes.
Update to Gerrit 2.9 and CollabNet’s Code Quality Gates Wizard
The biggest improvement independent of Teamforge is probably the upgrade to Gerrit 2.9, which comes with hundreds of new features itself. Gerrit 2.9 comes with an improved version of our code quality gate wizard for Gerrit. If you have not checked our features since the last major TeamForge release, you might have also missed our code quality gate wizard feature we introduced in August last year, so time to check it out now!
Ability to update repository review policies remotely (and version them)
Often requested by customers and finally available is a method to remotely updated the file which – depending on the repository review policy – decides how TeamForge SCM rights are mapped to Gerrit access rights. Eryk wrote a great blog post how you can edit this file for your own needs and introduce new workflows like GitFlow.
While Eryk’s post still assumed that you can change TeamForgeGerritMappings.xmlon the file system and restart Gerrit, our Eclipse Desktop and GitEye now provide a feature to do that remotely.
You will see a new option in the Gerrit nodes if you are a TeamForge site admin:
An XML editor opens with the current mappings file and if you perform your desired changes and click save, the new mapping will be deployed and applied to all repositories hosted by this Gerrit server automatically.
As Eclipse/GitEye is storing the file in refs/meta/config of the TF-Projects project, it is versioned too, so you can go back to an earlier version of your mapping file at any time.
Enhanced commit validation rules for all SCMs in TeamForge 8.0
Last but not least, there is a new feature in TeamForge 8.0 that applies to all integrated SCMs – Avanced commit validation.
As shown in the screenshot above, you can now define two more conditions for artifacts associated with commits for a given repository:
Artifacts must be in Open State: If you reference an artifact in your commit message (e.g. Fixes bug described in [artf1001]), this artifact has to be still open at the time you push this commit into the Gerrit server. Turning this setting on prevents developers working on tickets already closed without reopening them before.
Pusher must Own Artifact: If you reference an artifact in your commit message (e.g. First version of user story [artf2002]), this artifact has to be assigned to the TeamForge user pushing the commit to the Gerrit server. This setting enforces that developers are only committing work to their own artifacts
Stay tuned for more …
Having TemForge 8.0 out the door does not mean that you will have to wait a long time to see further Git related improvements. As I am writing these lines, we are already rolling our next point release, which will allow you to add all members of a TeamForge Team (the team concept has been introduced in TF 8.0) as reviewers to a change at once. Furthermore, we have improved navigation between Gerrit and TeamForge’s workspace once again and closer tie into TeamForge’s Single Sign On mechanism. Stay tuned for our next blog post when we officially release those (expected mid March).
Not the features you are looking for? Any improvement ideas? For any feedback, just comment on this blog post!
More from the Blog
View more

How does agile apply to an entire organization?

It took a pandemic to realize why digital transformation actually matters
