Look at our release notes to learn more about the development of Acrolinx for Git Hosting.
Released 28 April 2023
This version fixes a bug in parallel processing that could cause both the baseline and webhook workers to stop processing.
Released 20 March 2023
This small service release fixes a bug that caused the baseline to enter an infinite loop.
Released 16 February 2023
This is an important release with two new features that reduce errors in checks and in configuring files. We also updated our libraries to resolve a couple of high CVEs.
This release requires the following:
-
Acrolinx Platform version 2021.12 or later (Private Cloud only)
This release extends the implementation of retry mechanisms consistently for all HTTP calls. Previously, this was implemented only for those calls that often fail according to your observations.
The mechanism is used in all calls made to the Acrolinx API and the respective APIs of the Git Hosting providers that we support, namely GitHub and Azure DevOps Git. The mechanism performs retries upon receiving HTTP responses with status codes that indicate temporary unavailability of the servers and thus it increases the likelihood of successful responses. This results in reduced impact of the unavailability of the servers and increased reliability in the communication between the integration and the above mentioned platforms.
EDN to JSON Format Migration for Configuration Files and Repository RegistryThe Acrolinx for Git Hosting integration is now able to read its configuration and remote repository registry from JSON files. All three types of configuration files: the user-specific local configuration file, the global configuration file, and the repository level configuration file and the repository registry can be specified in both EDN and JSON, with JSON being the format that takes precedence.
How the remote configuration files and the repository registry are read
If the integration detects a JSON file, it reads the remote configuration from that file and it ignores the EDN configuration file. The remote EDN configuration is read if and only if there’s no JSON file present in the repository.
The above reading rules and format precedence apply to the repository registry file as well. We have provided support for both reading and writing of the repo state from and to the JSON repository registry file.
Support for JSON comments
The JSON format doesn’t support comments, however, we have provided support for comments as objects and key value pairs where the comment object name or key name starts with two forward slashes (//).
For example:
{ "//comment001": "A comment",
":foo0": [{"//comment0001": "A comment inside an array"},
"foo"],
":foo1": {
"//comment001": "Yet another comment",
":foo2": "foo2"
}
}
When the files are read, the comments are ignored. For future compatibility, we recommend the comment keys to be unique.
Naming convention for the configuration options
Note that the naming convention for the configuration options hasn’t changed, so when you specify the configuration options in your JSON files, make sure they start with a colon (:).
Naming convention for the configuration files
You need to make sure that the user-specific local configuration file ends in a .json extension. The global configuration file should be named as: global-config.json, the repository level configuration file as: .acrolinx-config.json and the repository registry files as: repositories.json.
|
Dependency (version) |
CVSS Rating |
CVE |
Found in |
|---|---|---|---|
|
org.eclipse.jetty/jetty-client ( 9.4.44.v20210927) |
LOW HIGH |
CVE-2022-2047 CVE-2022-2048 |
o.github.atomisthq/jibbit > com.cognitect.aws/api > com.cognitect/http-client |
|
com.github.jnr:jnr-posix (3.0.53) |
HIGH |
CVE-2014-4043 |
com.unbounce:clojure-dogstatsd-client@0.7.0 > com.datadoghq:java-dogstatsd-client@2.11.0 > com.github.jnr:jnr-unixsocket@0.27 > com.github.jnr:jnr-posix@3.0.53 |
Released 28 December 2022
This is a huge release jam packed with new features and bug fixes. Oh, and you might have noticed the new name! Read on to see all the exciting things we’ve added in this release.
This release requires the following:
-
Acrolinx Platform version 2021.12 or later (Private Cloud only)
We have dropped support for the following:
-
GitHub 2.0.x, 3.1.1, 3.2.0, 3.3.0, 3.4.0, and 3.5.0.
The GitHub and the Azure DevOps Git integrations now have a common source code base. They’ll now be available as two different git service providers under one integration, the newly released Git Hosting 4.0 integration. Upon installing the integration, you can configure which integration you want installed.
Updated Configuration OptionWarning
This is a breaking change.
The configuration option :secret is now called :gh-secret. Please change your main config file accordingly.
Most configuration options are now supported for Azure DevOps Git pull request processing. See the end of the release notes for more details.
Decreased the Event Queue Delay from 10 Seconds to 0.1 SecondsBecause of significant improvements of the GitHub cloud system (the git service itself), we’ve been able to drastically decrease the event queue delay from 10 to 0.1 seconds! In practice, it means that the comments and status are now posted to the git hosting service (GitHub or Azure DevOps) up to 10 seconds faster.
ACROLINX_LOGGING_TARGET Option RemovedThe environment variable ACROLINX_LOGGING_TARGET that was used to redirect the log output to the standard output has been removed due to a change in the logback library.
We recommend the following approach:
Inside the JAR, the file logback-stdout.xml can be used to redirect the log output. It is on the classpath and can be used as follows:
java -Dlogback.configurationFile=logback-stdout.xml -jar JARFILE ...
This will redirect the log output to standard output.
Notice
The file logback-stdout.xml was already included in the JARs of the versions Acrolinx for GitHub 3.6.0 and Acrolinx for Azure DevOps 1.1.0. You don't need to synchronize any deployment script changes with the integration upgrade.
The user interface of the Git Hosting integration has been removed. The main reason is that all the information provided via the former user interface is now available via command line options and the log system. This means that we can spend more time on new features, rather than maintaining an old, unused one!
With Azure DevOps 1.1, the persistent session ID returned by the Azure DevOps system was printed in some log entries. This has been fixed at the level of the exception system (HTTP headers aren't anymore printed to the log output in those exceptional cases).
Acrolinx Ignored Files When Config Option:allowed-filename-matches Was a String
A bug has been fixed for the configuration option :allowed-filename-matches . Previously when the value of this configuration option was a string (not a vector of strings), the integration wouldn’t check any files. The configuration option now works as designed.
Current differences between GitHub and Azure DevOps support:
-
The Azure DevOps Git mode supports only pull request events processing.
-
The configuration option
:ignored-senderscan mean different things based on differences in the APIs of those services:-
GitHub: username
-
Azure DevOps: email address
-
-
The configuration option
:use-skip-labelrefers to the pull request label in GitHub and to the pull request tag in Azure DevOps (different terminology between the git service providers). -
The configuration option
:allow-merges-from-defaultisn’t yet supported on Azure DevOps Git.
Released 19 October 2022
This release, we've improved the way that Acrolinx checks your files. We've also taken care of a couple of vulnerabilities in third-party libraries. That said, we recommend that you update to this version of Acrolinx for Git Hosting.
Acrolinx for Git Hosting version 3.6.0 requires the following:
-
Acrolinx Platform version 2021.03 or later.
In the past, you could send pull requests to the Acrolinx Platform in parallel, but they were processed sequentially. This meant that the average number of files in each pull request affected the processing time. We've improved this!
Acrolinx now processes incoming pull requests as quickly as possible and in parallel. With this improvement, the Acrolinx can make full use of all active language servers. Acrolinx will send as many files to the Acrolinx Platform as possible, but no more than what you configure for :acrolinx-parallel-workers. Read more about this in Configurations.
You can now send the JAR log output to the standard output. To do this, set the environment variable ACROLINX_LOGGING_TARGET to the value stdout. Learn more in our article Logging and Monitoring.
We found a couple of vulnerabilities in the third-party libraries that we use. That's why we've updated the library to a version where the vulnerabilities no longer exist. Time to do your part – go ahead and update your Acrolinx integration!
For more details, see the National Vulnerability Database.