What’s new in Eficode ROOT: March 2024

Request changes on merge requests (MR)

Communication is hard. We all know that. Oftentimes it’s communication (or a lack of it) that can prove to be the “make-or-break” for many things in life. It’s no different when it comes to code reviews.

Feedback given using the approve/deny logic in a merge request is, in a way, devoid of ambiguity. The same can’t always be said about comments left on an MR. This is where GitLab 16.9 aims to improve things.

The introduction of the new request changes option for merge requests allows you to convey your thoughts to other participants a bit more concisely. It serves as a better platform to submit your critique and feedback that you think should be addressed before the code can be merged.

It is worth noting that the feature is currently there to improve the communications aspect, not to enforce anything. Concluding a code review with request changes does not actually block the MR from being merged but rather serves as an indication that the MR could use some finishing touches.

Updated UX for CI/CD variables

While the CI/CD variables feature in GitLab has been quite usable for some time already, it has had its caveats that have resulted in less-than-optimal usability and, in some cases, the need to come up with ways to work around the limitations of the feature.

GitLab 16.9 ships with a series of improvements to CI/CD variables features to make the user experience more fit for purpose. Improvements include things like:

• Informational validation error message for masked variable creation when the input value does not meet the requirement criteria.
• Proper inline help text for the “Add variable” screen to aid in getting it right the first time.
• The “Value” field in “Add variable” screen is now resizeable to accommodate longer variable values like file contents.
• There’s also a new optional “Description” field for group and project variables to make it easy to describe the use case of a particular variable.
• And last but certainly not least, it’s now a lot easier to add or edit multiple variables as the “Add/Edit” variable drawer doesn’t close anymore when clicking on “Save,” considerably reducing the number of clackety-clacks required on the old electronical rodent.

Cancel with precision

If the context was anything other than GitLab, the concept of auto-canceling something (or, rather, someone, as it were) seems slightly… disconcerting, to say the least.

Luckily, it’s GitLab, and with this release, its auto-canceling option has been expanded with more flexibility over which exact jobs can be canceled by the auto-cancel feature. The introduction of the new auto_cancel:on_new_commit keywords provides more granular control over job cancelation. Check out the documentation for workflow:auto_cancel:on_new_commit for the exact spec.

Previously someone who could run a pipeline could also cancel a pipeline, which wasn’t necessarily what you would have wanted. GitLab 16.9 also introduces the possibility of controlling which user roles are able to cancel a pipeline. A project maintainer can now specify designated roles that are allowed to cancel a pipeline. You can even prevent cancellation entirely. Please refer to the documentation for customizing pipeline configuration on GitLab.com for more info.

More detailed security findings in VS Code

The GitLab Workflow extension for Visual Studio Code (VS Code) has received updates to its security findings capability, which are available on GitLab Ultimate. You can now see more details of your security findings that weren’t previously shown in VS Code, including full descriptions, solutions to the vulnerability (if there is one), a link to the location where the problem occurs in your codebase, and links to more information on the vulnerability.

GitLab Workflow extension for VS Code is available on Visual Studio Marketplace.

Expanded coverage for the rich text editor

The rich text editor introduced by GitLab 16.2 provides a WYSIWYG editing interface for someone who’s not a fan of the markdown experience. Until GitLab 16.9, the editor was only available in issues, epics, and merge requests.

This release expands the coverage of the new editor, making it also available for:

• Requirement descriptions.
• Vulnerability findings.
• Release descriptions.
• Design notes.

And there’s more!

There’s always more when it comes to GitLab. Head on over to the GitLab 16.9 release announcement for a complete overview.

Revisions to Remoting

The latest Remoting included with Jenkins LTS 2.440.1 deprecates the -jnlpUrl argument in the agent JAR in favor of a combination of -url, -name, and other arguments, such as -tunnel, where applicable.

If you are connecting self-hosted agents to your Eficode ROOT Jenkins, please make sure to review your current configuration options. The support for jnlpUrl will be completely removed in an upcoming Jenkins version.

Please refer to the Jenkins LTS 2.440.x upgrade guide for more information on this change.

Potentially breaking changes in an optional plugin

The pre-2.0.0 versions of the Generic Webhook Trigger plugin were incompatible with the “Trigger builds remotely” option in recent Jenkins LTS versions. When the “Generic Webhook Trigger” and the built-in “Trigger builds remotely” option were enabled in a job, it resulted in webhook triggers failing, as described in the bug report #290 for generic-webhook-trigger-plugin.

Previously you could have used the token value configured for the “Trigger builds remotely” option with the “Generic Webhook Trigger” as well, in addition to configuring a dedicated token for the plugin (dedicated tokens for the plugin were introduced all the way back in 2018). Due to the incompatibility, support for using a “shared” token is now dropped. You must configure a separate token for the plugin to trigger it.

Plus, the usual monthly updates

As always, there are a number of smaller incremental updates, fixes, and enhancements for other plugins as well. Due to the nature of Jenkins—all of them being the sort of snowflakes as they are—the list of applicable updates is slightly different on all Eficode ROOT Jenkins deployments.

Please reach out to your friendly Eficode ROOT support team if you have any questions on the specifics of your own little snowflake.

New OCI repository types

Our March release of the venerable JFrog Platform ships with comprehensive support for Open Container Initiative (or OCI for short) artifacts.

^{New “OCI” repository type in JFrog Artifactory 7.77.x UI.}

There's a new OCI repository/package type available for setting up your own self-hosted OCI registry (version 1.0.2) on Artifactory. Naturally you can now also use OCI to package your Helm Charts, making it easier to leverage the OCI benefits for delivering your charts.

If your JFrog is equipped with Xray, you'll also receive a full vulnerability scanning suite for your OCI repositories for both OCI and Docker images deployed to an OCI repository, including software composition analysis (SCA), and the JFrog proprietary Contextual Analysis and Exposures scans.

Starting with the OCI registry is as simple as it can be: Just create a new OCI repository, and off you go! When switching your Helm to OCI with Artifactory integration, the documentation for Helm OCI repositories might come in handy.

Custom global roles

The Projects feature was made available on all JFrog subscription tiers exactly two years ago, back in March 2022. Oh, how time flies!

Remember our release notes for March '22? The rambling in these has increased since then, hasn’t it? Or did we just gradually give up on editing this nonsense?  Maybe the raw material was always like this.

But I digress. Projects introduced a conceptually different approach to artifact management, with an added layer to represent the actual organization Artifactory was run in, in order to make it less of a simple filestore and more of an integral part of the whole development process.

In this froggy release, the role-based access control capability of the project layer has been expanded with support for customized global roles to fulfill any project artifact management RBAC needs you could possibly have. Documentation for global roles explains how to put the new custom roles to good use.

Not familiar with Projects? Check out the documentation for JFrog Projects to learn more.

Permission management version deux

This release of the JFrog Platform introduces the next generation of permissions model called— drumroll please—Permissions V2! It’s fully backward compatible with the previous V1 model. The new model aims to simplify the UI user flows for configuring permissions for different resource types, with an improved look and feel in resource-specific configuration options and so forth.

Check out the documentation for managing permissions to learn more about the change.

Support for scanning VMDK and OVA images

Our March version of Xray also adds support for scanning VMWare Disk Image files (*.vmdk) as well as VMWare images inside OVA archives (*.ova) in monolithicSparse or streamOptimized formats. Both MBR and GPT partition table formats are supported, but filesystem support is, at least for the time being, limited to the most popular options: XFS and EXT4.

What is Current, and how do I sign up?

SonarQube LTS (Long-Term Support) is the standard-issue SAST kit on your typical Eficode ROOT platform. And it’s great: It does what it says on the tin and doesn’t complain a whole lot about anything during its eighteen-or-so-month lifespan. Stable and predictable. And perhaps, dare I say it, a little bit… boring?

Maybe you’d like to have more pizzazz in your development pipeline? And what’s better for that than a bleeding-edge SonarQube? This is exactly what our Current line has to offer: The latest release as soon as it becomes available, all the flair and new features, quirks, breaking changes, and the other early adopter benefits you can think of!

Ready to take the red pill and see how deep the rabbit hole goes? If so, don’t hesitate to reach out to your Eficode ROOT service manager to learn more.

Java 11 support for SonarScanner is no more

And while we’re on the subject of breaking changes, here’s one for you. It’s the end—the end of Java 11.

Whilst everything else in SonarQube already ran on Java 17, running a SonarScanner on Java 11 has still been possible. Everything changes with SonarQube 10.4. Now it’s 17 all the way. It has been fully supported for quite some time already, so there’s no reason not to update.

Wondering which of your jobs run their SonarScanner on a deprecated Java?

^{Deprecation warnings shown for a project in SonarQube 10.x user interface.}

The SonarQube project UI has a separate warnings portion, which shows all the possible deprecations and other inefficient configurations present in your current Scanner settings. Including the Scanner Java version.

Making your Clean Code efforts visible

This release of SonarQube embraces your Clean Code efforts by making the results and benefits of going the extra mile visible.

Pull requests (PR) show issues that will be fixed

There’s no more need to guess what issues you’re fixing with your pull request. SonarQube now shows the issues that will be fixed even before the code is merged, making it easier to verify that the issues you intended to fix are actually resolved by the PR. This information can be viewed through the pull request summary view in SonarQube, as well as through the pull request decoration for all four supported CI platforms (Azure DevOps, Bitbucket, GitHub, and GitLab).

Improved issue overview for branches and software quality view for overall code

The branch summary screen has been updated to show the single count of issues for new code instead of the previously displayed separate issue categories (bugs, code smells, and vulnerabilities). This makes the UI overview more in line with the pull request decoration and summary views, further highlighting the issues (or the lack of them!) affecting new code.

The overall code tab has also been reworked to show a better overview of the whole codebase with software quality categories that have a count of high, medium, and low severity issues as well as the count of accepted issues.

Accepting issues appropriately

A “won’t fix” statement has its charms, but it doesn’t always deliver the message quite right. There’s the possibility of interpreting a “won’t fix” to have certain levels of “Nah mate can’t be bothered” associated with it. Sometimes quite correctly so…

SonarQube 10.4 adds the option to address issues that will not or cannot be fixed in a more appropriate manner. Developers can now mark an issue as “accepted” instead of “won’t fix” with a clear message explaining how the issue was judged to be acceptable and how accepting it contributes to technical debt.

The number of accepted issues will be shown on PR decoration and various summary screens in SonarQube, as described in the sections above. Clicking on the count of accepted issues anywhere in the UI will bring you to the list of accepted issues with details on why they are what they are.

Faster scanning

Previously SonarScanner fetched all analyzers from SonarQube regardless of the languages present in the project. This logic has now been streamlined: The scanner will only download the analyzers that are actually required based on the files and the languages used in the project. Small streams, little acorns, and all that.

It doesn’t end there

SonarQube now also supports analyzing Helm Charts for Kubernetes deployments. The same Kubernetes rules that are applied to other YAML files also now apply to the Helm variety.

Seventeen hundred rules in the Learn as You Code feature have been graced with improvements and additions to the “How can I fix it?” and “More info” sections.

And to top it off: No SonarQube update would be complete without language updates. Version 10.4 ships with revisions to JavaScript/TypeScript, Java/Kotlin, C/C++, .NET, and Python. Please find details on the SonarQube 10.4 release announcement.

For further reference on the more technical side of things, you can also have a look at the SonarQube 10.4 release upgrade guide.