Redesigned permission pages
Access privilege configuration in Bitbucket is a three-level stack, ranging from instance-wide global privileges via project level configuration all the way to repository based privileges. Sometimes it can be quite difficult to identify the effective permissions on each level – who actually has access, and to where?
Atlassian has now redesigned the permissions pages under Project and Repository settings to display all effective permissions - both explicit and inherited - and has added filtering capability to help in managing permissions in larger projects with many users and groups.
Redesigned Repository permissions page in Bitbucket 8.6
By default the view on repository level, for example, only shows the explicit repository level permissions. To view the inherited permissions from other levels, you can conveniently select the ones you are interested in using the “Permissions” dropdown menu above the results.
Permission view filter dropdown menu in Bitbucket 8.6
It is also possible to export the global list of permissions across all projects and repositories. A great tool for your compliance and auditing needs. See the Users and groups documentation on atlassian.com for more information on the export utility.
Fine-tune the secret scanning
Our previous Bitbucket release 8.3 introduced a new Secret Scanning feature, which helped in detecting potentially dangerous stuff being exposed in the code base accidentally.
It was a bit trigger-happy, wasn’t it? Yeah, we noticed it too.
This release of Bitbucket upgrades the feature to the next level. Rules can now be made more granular and configured for projects and repositories. Previously secret scanning was only configurable on an instance-wide global level. Still, now project admins have the possibility of tuning the scanning settings on project and repository levels as well. You can override the global rules, add your own rules or exclude repositories from scanning altogether.
Check out Secret Scanning on atlassian.com to learn more about the new capabilities of secret scanning.
Be more consistent with PR default tasks
It is quite typical to have certain procedures and checks to be carried out whenever feature or bug fix branches are merged into the main codebase. You could have possibly used the Bitbucket PR tasks to provide a nifty checklist of items to go through.
This release of Bitbucket introduces an option to automatically create a set of these tasks whenever a pull request is opened. Admins can configure the default tasks on project or repository levels, and they can be set to apply to any pull request or can be tailored to specific branches.
Combine your new default set of tasks with the No incomplete tasks merge check to ensure that every pull request goes through all the appropriate hoops before merging.
News from the plugin ecosystem
Awesome Graphs for Bitbucket
This version of Awesome Graphs moves the Commits graph to a more appropriate place. It can now be found under reports by the name of Commit Activity Report. This change will help in unifying the app’s features and to ensure better user experience.
The Users filter in Top Committers Report has been made sleeker by removing the largely unnecessary contributor (real) names, leaving only the more relevant Bitbucket usernames. Combine this with the multi-select filter and you’ll find the relevant users and create reports in no time!
Security for Bitbucket: Enhanced Secret Scanning by Soteri
This release of Security for Bitbucket adds support for detecting new fine-grained GitHub personal access tokens. It is worth noting that this update contains a rule definition, which will mark old scans as out of date.
Sensible user provisioning on SCIM (beta)
If you have your GitHub Enterprise hooked up to an external user directory, you may be familiar with the external Team Sync utility, which can be used for provisioning user accounts to GHES based on the data in the external directory. While it serves its purpose, Team Sync can seem slightly out of place in a modern SAML/SSO-based environment.
GitHub Enterprise Server 3.7 ships with a private beta version of support for SCIM (System for Cross-domain Identity Management) for automated user and group provisioning. This can greatly simplify the user provisioning for SSO setups. It's particularly useful, if you happen to use the Eficode ROOT Team Management. It supports SCIM out of the box!
Please reach out to your friendly Eficode ROOT support team if you'd like to try out SCIM provisioning on your GHES instance.
Signing commits with an SSH key
Previously Git and GitHub Enterprise supported commit signing using GPG keys of X.509 certificates. Commit signing seems like a decent idea – on paper, as many of us have learned over the years. The recent addition of SSH public key based signing support takes away a lot of the clunkiness related to using GPG or X.509. This may just be it.
If you already use an SSH key to authenticate with GitHub Enterprise, you can conveniently use the same key for signing your commits as well. Simply upload the same key again and configure the user.Signingkey options on your Git client and you’re off to the races!
Check out GitHub SSH commit signature verification on github.com for specific on setting it up.
Enhanced repository policy management
Have you found the default repository usage policy a bit too lax in GitHub to fit the needs of your organization?
GitHub Enterprise Server 3.7 ships with a solution. There are new policy enforcement options available to control the way repositories can be created or forked:
- Enterprise owners can prevent users from creating repositories owned by their user accounts.
- Enterprise owners can also control where users can fork repositories using preset combinations of organizations, limit forking to the same organization as the parent repository, or you can disallow forking altogether.
GitHub Enterprise Server 3.7 also features a configurable policy for blocking potentially destructive pushes by limiting the number of branches and tags that can be updated by a single push. Repository administrators can set the limits in repository settings.
Glab becomes the official GitLab CLI
GitLab has adopted the open source project glab (by GitLab Hero Clement Sam), which will be the foundation of GitLab’s native CLI experience. As the name suggests, GitLab CLI brings GitLab functionality to your terminal, making it possible to work with Git and your code without any browser-based ClickOps.
With the current version of CLI, you can do the following without leaving the comfort of your terminal:
- Review issues assigned to you.
- Created branches and merge requests for those issues.
- Check the status of your pipelines.
- Approve and merge MRs.
Be sure to read the "Put `glab` at your fingertips with the GitLab CLI" blog post on gitlab.com to learn more about the history, current state and future plans for the native CLI. Or for a TL;DR you can head directly to the GitLab CLI installation instructions on gitlab.com.
Signing commits with an SSH key part deux
Well, what do you know! Signing commits with an SSH key is hot. Like our January release of the other popular Git platform GitHub Enterprise (see above), GitLab 15.7 also ships with SSH key commit signing support.
Previously you could have used a separate GPG key or an X.509 certificate to sign your Git commit. With the introduction of SSH key commit signing, you can now reuse your authentication key pair to also sign your commits. If you’re already connecting to Git over SSH, it’s simply a matter of adding three lines to your local Git configuration and all your future commits will be signed.
Check out "Sign commits with SSH keys" on gitlab.com for further details.
And much more, as always
This release of GitLab ships with other exciting features, such as the first GA release of GitLab’s proprietary browser-based DAST analyzer for Ultimate users (link), support for CI/CD agent connection sharing with personal namespaces (link), a masking feature for hiding sensitive portions of webhook URLs (link) and a whole lot more!
All changes in this release are covered in great detail on the GitLab 15.7 release blog on gitlab.com. Be sure to check it out!
Updates to UI
This release of Jenkins continues with the UI modernization effort: notification design has been updated, and there are improvements to the navigation, buttons, and test overview bar. Various icons across the application get a refresh.
On the left: updated icons in Jenkins 2.375.1 LTS
While the slightly controversial all-blue weather icons introduced last spring were undoubtedly very cool and minimalistic, they weren’t particularly readable. This release brings the colors back, sacrificing some of the coolness for real-life usability.
The usual monthly Jenkins
There’s also a usual round of plugin updates, with fixes to some usability issues and minor security-related concerns. Nothing drastic and nothing breaking. Nice and easy.
As always, don’t hesitate to contact the friendly Eficode ROOT support team for a list of updates specific to your Jenkins instance.
Minor version update for LTS
Our January release contains a minor bugfix update to SonarQube LTS (to version 8.9.10), but there’s more to come!
Plus one for SonarQube Current coming out in February
The AWS CDK analysis has been further enhanced, and there are also six brand new rules for C++20 Concepts to help you update your existing code to concepts and ensure that the code is top notch.
Imminence of SonarQube 9 LTS
The previous LTS (8.9) was released back in the summer of 2021, which means that we are nearing the end of the ~18 month life cycle of a SonarQube LTS major release. We would expect the next LTS release to happen during Q1. There have also been some SonarQube Community posts from SonarSourcers indicating that Q1 is indeed in their targets as well.
Chances are the upcoming 9.9 will be the release to become the next LTS.
Whilst the new features of 9.x are probably already familiar from our Current series, other changes can necessitate adjustments in CI pipelines and such. The biggest breaking change being the phasing out of Java 8 support. With SonarQube 8.9 it has still been possible to run the Scanner on Java 8. This will end. Only Java 11 and newer will be supported going forward.
As there are certain expectations of the stability of an LTS based application, we’ll do our best to ensure the smoothest possible upgrade path. You can expect a lot more communication on this subject as soon as the new LTS is out.
Eficode ROOT Team Management
Eficode ROOT Team Management receives a round of bug fixes and updates for January. Internal components and dependencies have been updated to newer versions, and there are also corrections to some minor UI niggles.
Please navigate our documentation at docs.eficode.io to see the complete release notes or learn more about Eficode ROOT Team Management.
Nexus IQ Release 150
This release of Nexus IQ ships with a new feature called Data Insights. It’s an experimental set of analyses available in the IQ server. Data Insights aims to provide a new perspective on open-source consumption patterns and technologies within your organization.
The current version comes with three insights:
Migration Scorecard, a visual representation of the quality of component upgrade decisions in Java development teams.
Stack Divergence, an analysis which provides a comparison of popularity of components in your tech stack to what the rest of the industry uses. This can help you identify where you’re in line with the de facto “standard” of the industry, and where more obscure components are being used.
Nudges and Anomalies insight provides metrics on your Nexus Lifecycle platform usage patterns and trends.
Published: January 3, 2023