What’s new in Eficode ROOT: September 2022

Archive your unused repositories

We all know products that are alive and well, but no longer actively developed or maintained. The riddle is, what to do with the source code? It should still be stored somewhere safe and accessible - just in case - but avoid anyone mistaking it for an active project.

Bitbucket 8 has an answer: archived repositories.

You can now set any repository in your project as archived. When you archive a repository, it gets excluded from search results, the repository itself becomes read-only, and creating and managing pull requests and branches gets blocked too. An archived repository can still be cloned or forked, and it is possible to unarchive the repository in case the maintenance of the code resumes.

The ability to archive repositories helps keep the code readily available in Bitbucket but prevents any accidental code changes. Isn’t it lovely!

Learn more about the feature at Archive a repository on atlassian.com. 

Create repository permission

Project admins can now grant users and groups the new Create repository permission, which, as the name suggests, allows the user to create new repositories for the project. Previously only Project Administrators had the right to do so.

The new repository permissions can be a convenient way to reduce the workload of project admins.

Check out the Using project permissions documentation on atlassian.com for fine-grained details. 

Secret scanning for detecting accidental exposure

These days, software code often needs to deal with all sorts of sensitive information on a code level. These could be passwords, tokens, private keys or .pem key files, or anything else. Sometimes, these secrets are accidentally embedded into the source code and pushed into the project repository.

Once these secrets are pushed to the repository, they can be hard to remove. Given the distributed nature of Git, cleaning the version history on the Bitbucket server side can’t touch local copies on developers’ workstations.

To help with dealing with these issues, Atlassian has introduced a new Secret scanning facility in Bitbucket 8.3.

Bitbucket scans your repositories for secrets and triggers notifications when possible leaked secrets are detected within new commits. Email notifications are sent to everyone involved in the commit history of the detected secret. If you have a specific type of entity, like a proprietary secret pattern, the scanner can be customized to detect regular expression patterns of your chosen file paths.

Bitbucket scanning is enabled by default.

Learn more about secret scanning on atlassian.com. 

Various other improvements

Bitbucket 7 introduced new, redesigned pull requests (see Bitbucket 7 release notes on atlassian.com for details). With Bitbucket 8, all the diff views were moved to this new format for a faster and more consistent experience.

The SSH keys and Access keys pages have been freshened up. To keep your code safe, Bitbucket will analyze your keys and highlight the ones that aren’t considered secure enough.

And there’s more, like the new build states (UNKNOWN and CANCELLED) in the Builds view for CI/CD integration, the possibility to view deployment and build information in the Jira cloud, and so forth. 

Now onto the deprecations

If you’ve developed your integrations or automation against Bitbucket APIs, you might want to check the API changelog at atlassian.com for deprecations and removals in Bitbucket 8.

This major release also deprecates server-side support for Windows. If Linus ever had an evil plan to take over the world, we think it might be working. At Eficode ROOT, everything runs on Linux, so this is not much of a concern for us. The support ending, that is.

Support for PostgreSQL 9.6 as the database engine for Bitbucket has also been phased out. Upgrading the database can mean a couple more minutes during the service break. Don’t worry, we’ll let you know if your platform is affected and - naturally - take care of it.

Check out the Bitbucket release notes at atlassian.com for a complete list of changes in Bitbucket 8.x. 

 

Application tunnels to Atlassian Cloud

Previously you could use Application Links for setting up integration between self-managed (Data Center, Server) Confluence and Atlassian Cloud products. But Application Links were merely a theoretical possibility in many enterprise environments: using them required exposing parts of Confluence to the public internet to allow incoming connections from Atlassian Cloud. In many cases, doing that would have been undesirable or even technically impossible.

With the new Application Tunnels official add-on, it is possible to create a secure network tunnel between your organization in Atlassian Cloud and the Atlassian products running on the Eficode ROOT platform. An application tunnel only requires outbound connections from Eficode ROOT.

The feature is available not only for Confluence but also for Bitbucket, Jira, and Jira Service Management. 

Application Tunnels can be particularly useful, for example, when your Jira Service Management runs on a non-public Eficode ROOT network, but the associated Confluence documentation site runs on Atlassian Cloud.

If this piqued your interest, check out "What are application tunnels?" on atlassian.com or get in touch with the friendly Eficode ROOT support team for more information.

IP restrictions for Git over SSH

GitLab introduces the possibility of limiting SSH access to Git to a trusted set of IP addresses. Until now, it was only possible to configure API and UI access restrictions, but they would block SSH entirely.

Task management for Issues

Previously you could only do task management using workarounds like markdown checklists within the issue description field. While it sort of did the trick, it was not particularly useful.

Now issues can be split into smaller, separate child items – tasks. Task management is available directly in the issue view, under the Child Items widget.

 

Tasks can be opened directly from within the issue to reveal the task’s weight, status, and description. GitLab will also add labels, milestones, and iteration fields to each task in an upcoming release.

Approval rules for protected branches

Adding approval rules for Merge Requests was possible earlier as well, but those rules would apply to all branches – including short-lived or experimental branches. The behavior of the rules was not always desirable and could end up hampering the development workflow unnecessarily.

With this release, you can now configure your MR approval rules only to apply to protected branches. Keep your sensitive branches in check by enforcing proper workflows without slowing down development on other branches.

And a whole lot more

Check out the release notes for GitLab 15.2 and GitLab 15.3 on GitLab.com to learn about all the new features, enhancements, and fixes.

The usual suspects

Jenkins LTS gets a minor bump from 2.346.2 to 2.346.3 LTS, which fixes numerous bugs, including Denial of Service faults (CVE-2022-22970, CVE-2022-22971) in the embedded Spring Framework.

There’s also the usual round of plugin updates with no drastic or breaking changes indicated by their respective change logs. As always, please reach out to your friendly Eficode ROOT support team for a list of updates specific to your snowfla… uh, I mean, Jenkins.

The end is nigh for Java 8

The next LTS (2.361.1), officially released on the 7th of September, will end an era in Jenkins Core. This release will not run on Java 8 anymore.

Many different factors necessitate this change. 

Firstly, Java 8 is old. It was released in the spring of 2014. It has many deficiencies compared to its successors.

Secondly, Jenkins uses a lot of 3rd party components and libraries. Many libraries have already switched to Java 11+, meaning that Jenkins is stuck with older versions to retain Java 8 compatibility.

Thirdly, timing is everything. The use of Java 8 has peaked and steeply declined since 2021. The adoption curve of Java 11 is the polar opposite of that of Java 8. Not that dissimilar to the trend of energy prices in Europe in 2022. But I digress.

Still not convinced? Don’t worry; Jenkins has got you covered with many more good reasons on their "Jenkins requires Java 11 or newer" blog at jenkins.io.

Do I need to stop using Java 8?

No. You don’t.

Java 8 is not getting removed from the build environments or tool configurations in Jenkins. It will still be available and usable; no changes here. If you have been using an ancient Jenkins Agent image, you may see the default Java version on the Agent switching from 8 to 11. In this case, you’ll have to reconfigure your job to specifically select a Java / JDK 8 from the list of available tools if the build explicitly requires Java 8.

What about Maven?

Sadly, if you still use the legacy Maven Project type with Java 8, these will stop functioning. The Maven Project functionality in Jenkins is tightly integrated with the Jenkins Core code. All jobs using the integration will need to be run on Java 11.

You can still run Maven commands on Java 8 in a Pipeline or with the “Execute Shell script” option in a Freestyle project. You can also reconfigure your Maven project (pom.xml) to produce a Java 8 compatible build by setting up the Maven compiler source and target options (see the documentation on maven.apache.org) but run the build itself on Java 11. You can update your configs right away, there’s no need to wait for the builds to break first!

So what changes?

Jenkins Core will run on Java 11 – most Jenkins instances in Eficode ROOT already do.

Jenkins Agents will run on Java 11 – and most Jenkins Agents in Eficode ROOT already do. If you are connecting your agents to Jenkins as part of Eficode ROOT, ensure that you have the latest agent.jar and run it on Java 11. If not, you can do the switch at any time; no need to wait for the next release.

All plugin code needs to be compatible with Java 11. Most, if not all, plugins available via Jenkins “marketplace” have been updated or verified to work. The availability of plugins may become an issue with obscure third-party closed-source plugins that are not very well maintained. Very few closed-source plugins are used in Jenkins setups in Eficode ROOT, so we don’t expect significant problems.

SonarQube Current upped to 9.6

Focus on security

Security has been in the spotlight for SonarQube 9.6. There are six new Security Hotspot rules for Kubernetes. For building and designing better AWS implementations, there are five new rules for JavaScript use of AWS CDK and seven new Java rules covering Lambda development, use of AWS Client and AWS SDK, and access key security.

Following the introduction of new token types in SonarQube 9.5, this release takes the security of these tokens further by introducing the ability to set token expiration. You can use Global settings to enforce token lifespan, or the user can set it during token generation.

SAML SSO implementation in SonarQube 9.6 has been enhanced to support request signing and assertion encryption.

Taint Analysis detection has been improved by extending the coverage to the 100 most-used Java libraries. There are also Taint Analysis logic updates which help in reducing false positives - and in finding more true positives.

Ever faster Java analysis

Even though previous releases of SonarQube have already significantly improved the analysis speed for Java code (and various other languages as well), this one will be even faster!

SonarQube 9.6 introduces incremental analysis for Java Pull Requests. There’s a new server-side caching mechanism that allows SonarQube to limit the PR analysis to only the changed files (instead of scanning all files in earlier versions) while still performing a thorough analysis. Incremental analysis can cut down the processing time for a PR to a fraction of what it was before.

Now that the cat is out of the bag, you can expect to see the same improvements for other languages in future SonarQube releases!

You can find this release’s complete list of changes at the SonarQube 9.6 release announcement on sonarqube.org.