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.

 

Site wide role with read access to all repositories

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).

Default Access Permissions in TeamForge

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).

Anonymous clone URLs

 

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.

 Gerrit project menu icon

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.

 

Gerrit changes for the connected TeamForge 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).

 

TeamForge -> Gerrit -> GitWeb Navigation Flow

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!

Quality Gates for Gerrit

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:

Load repository mappings

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.

Save repository mappings

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.

Advanced commit validation rules

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! 

Johannes Nicolai

Johannes Nicolai is CollabNet’s Development Manager leading all Git and Gerrit related development efforts. Furthermore, he is responsible for CollabNet Connect /synch, CollabNet’s platform to integrate TeamForge with third party ALM platforms. Johannes holds a Master of Science in IT Systems Engineering from Hasso Plattner Institut Potsdam and is a Certified Scrum Master. Before joining CollabNet five years ago, he was doing consulting on user centric design, developing cryptographic software and architecting SAP integrations. He is an Open Source enthusiast and contributes to many projects (check out https://www.ohloh.net/accounts/10619 for details).

Tagged with: , , , ,
Posted in Git, News, TeamForge
5 comments on “Top 3 Git Features coming in TeamForge 8.0
  1. Nicholas Gulrajani says:

    A great write up with explicit examples.

    • Germain says:

      Great to be able up update the Teamforge gerrit access right mapping file but unfortunately only limited to site admin…. Why such limitation ? and when do you plan to open it to project admin ?

      • Hi Olivier,

        changing repo categories is a very powerful mechanism. Inexperienced project admins can easily create situations where trouble shooting will be hard to do, especially if an existing repo category (like default, optional review, mandatory review) got overridden?
        Would you allow to override or just to add additional categories at the project level?

        We are looking into extending the feature to project admins in H1 2016, but would like to get your feedback on questions like the one above to have a good balance between flexibility and maintainability.

        Best, Johannes

        • Germain says:

          Hi Johannes,

          In fact my idea behind was to have the capability at teamforge project level to define our own Gerrit access right template.
          As a project admin I would then have the capability to:
          – Create from scratch my own Gerrit access right template for my project gits and have the capability to share it for other project
          – Reuse an already existing template (read only) from another project that make it public and create my own by modifying some permissions to adapt it to my branching policy.

          I would also like very much an option to the repo category mode to disable automatic configuration reloading to support the following use case
          – override configuration for a a specific Git repository (restrict access rights to specific branches for example), disable commit on master branch for forked/mirrored repository, ….
          – temporary override a repository configuration. Let’s consider for example the mirroring of an external Git. You may want to enable the force push on the master branch only during the mirroring to override the default commit created by Teamforge at git creation

          The current solution to switch to the custom mode to do that is too restrictive since when switching from repo category to custom you fall back to the preassigned source control permissions (View Only, Commit View, …). I have currently log a ticket on the latest matter

          BR
          Olivier

          • Hi Olivier,

            thanks for your feedback. As part of our pull request feature, we plan to implement protected branches which can be handled separately in the access right mappings of a repo category.

            Just in case you did not know: if you add any access rights to an internal Gerrit group or have define an access right on the parent project level, those will not be overridden during rights synchronization. You could use this to temporarily enable push on the master branch as well.

            I realize that there are still a lot of reasons for having repo categories on the project level, but thought the info above might help you to deal with the situation until we tackle this in our road map.

            Best, Johannes

Leave a Reply

Your email address will not be published. Required fields are marked *

*