Changelog

Follow Us With Twitter
Copy RSS Link
Back to all posts
Jan 25, 2023
ENTERPRISE SERVER v3.17.0
Previous

Improved role-based access sync from GitHub

Managing repository permissions and access settings for users on your GitHub and DeepSource organizations separately can be tedious as your team grows. We’ve made several improvements to how we sync permissions from GitHub to simplify this and eliminate manual effort.

  • Repository-level permissions: Repository permissions to users inherited from a team on GitHub are now correctly synced on DeepSource. Previously, only direct repository collaborator roles were synced, leading to an inconsistency in the repositories that a user could see on GitHub and DeepSource. Read more in our docs.
  • Base permissions: To help you bring parity with base permissions on GitHub, we’ve added a new No Permission option to Member Base Permissions in your team’s access control settings. Selecting this will allow members read-only access to public repositories by default. They will not have any permissions on private repositories unless some level of permission is inherited from a GitHub team or through being added as a direct repository collaborator. Read more in our docs.
  • Default Base Permission: When you connect a new GitHub organization, we will automatically sync the organization’s base permission from GitHub to DeepSource. Previously, this setting defaulted to “Maintain” on DeepSource.

Please note that automatic sync of access on repositories can affect your occupied seat count on DeepSource. For instance, if a user has a Contributor role on DeepSource but a Member or Admin role on GitHub, their role will be upgraded, and they’ll now occupy a paid seat on DeepSource. To help you keep track of this, the source of a member’s addition to the organization or a repository is now shown in the list of members in Organization → Settings → My team and Repository → Settings → Repository members.

New in Analyzers

  • We’ve added 41 new checks across our Analyzers:
  • We’ve added Autofix™️ support for four checks:

New in Enterprise Server

  • RabbitMQ High Availability: As a first step towards ensuring high availability of DeepSource Enterprise Server, DeepSource now runs RabbitMQ in HA on standalone installations.
  • Export logs to SIEM tools: You can now export your DeepSource Enterprise Server logs to the SIEM tool of your choice. Read more in our docs.

Fixes and Improvements

  • We’ve fixed an issue where the test coverage Analyzer was timing out due to a parsing issue in some test coverage report formats.
  • Added the ability to regenerate the DSN for a repository from the dashboard and the API. In light of the recent CircleCI breach, we strongly recommend that all users using CircleCI for their repositories rotate their DSNs on DeepSource. You can read more about it here.
  • Setting the enabled attribute as true is now optional in the .deepsource.toml configuration file and will be true by default. If you want to disable an Analyzer, you can comment out that Analyzer entry, or add enabled = false manually in your deepsource.toml file.
  • The Scala Analyzer now automatically detects the correct Scala version even if the version meta field in the .deepsource.toml is not specified. If you’ve already set this field value, we recommend you remove it and let the Analyzer handle it appropriately.
  • Our reports now include legends in the charts to help you quickly understand the data.
  • On the run history page, the checkbox to Autofix™️ was behaving incorrectly. This has been fixed.
  • We’ve fixed an issue where the Python Analyzer was not raising flake8-compatible issues for some Python 2.7 repositories.
  • We’ve disabled obsolete issues in the JavaScript Analyzer that enforced coding styles: JS-0229, JS-0083, JS-0113.
  • We’ve updated the issue description for JS-0002 with instructions to prevent code that runs in the NodeJS environment from being flagged.
  • We now automatically exclude auto-generated and designer files from the C# Analyzer analysis. Ideally, directories such as bin and obj should be excluded when the code is committed. However, if they were added in the commits, we were incorrectly running an analysis on them.
  • The maximum JSX nesting depth for JS-0415 has been increased from 2 to 3, as 2 was a bit too restrictive.
  • We’ve improved JS-D008, an issue that flags incorrect use of Array.prototype methods. We now cover more methods and have an improved issue description to explain possible fixes.
  • The Python Analyzer was raising both FLK-E501 (Line too long) and FLK-W505 (Doc line too long) on long extraneously long docstrings. Since this was noisy, we now raise FLK-W505 only in those instances.
  • We’ve fixed several false positives in this release:
  • JAVA-W0324: We’ve fixed an issue where the @SuppressWarnings("unused") annotation was not respected, resulting in false positives.
  • JAVA-W0324: We’ve fixed an issue where we incorrectly detected privateMethod as unused for the proper usage of private methods declared inside nested classes.
  • JAVA-W1025: We’ve fixed an issue where we incorrectly detected privateMethod as unused for private fields declared within nested classes, which were used in an outer class.
  • JAVA-P0361: We were incorrectly reporting this issue this when there was a use of Map.keySet() followed by the usage of Map.get() with the same map and the same key, even if the second access was behind some condition (such as an if statement). We’ve fixed that.
  • JAVA-W1036: We incorrectly reported this issue when the actual (the type at the usage site) generic type of a method’s parameter was java.lang.Object, and the argument passed was also of type java.lang.Object. We now correctly infer the expected generic type and avoid reporting this issue when the expected generic type and argument type match.
  • JAVA-W1069: We were incorrectly reporting this issue for certain imports. We’ve fixed this by using better algorithms to detect what types/methods/fields are imported and which are used.
  • JAVA-W1042: We were incorrectly reporting this issue for methods that throw generic exceptions (like java.lang.Exception), even if the throw was added due to a call within the method that raised the exception. Now, the Java Analyzer will attempt to discover whether any checked exceptions are thrown by some method called, and if there are, it will avoid reporting this issue.
  • JAVA-W1025: We were incorrectly reporting this issue for private fields that were annotated with @MockBeans. We’ve fixed that.
  • JAVA-E1017: We were incorrectly reporting this issue for methods that called their overloads when the overload was passed casted versions of the method’s initial arguments. We’ve fixed that.
  • PYL-W0201: For relative imports inside packages, we couldn’t infer the base classes for certain classes. We’ve fixed that.
  • GO-W1027: We’ve fixed an issue where we incorrectly flagged an empty slice literal used to declare a variable for types other than a slice. We’ve fixed that.
  • RVV-B0013: We’ve fixed an issue where we didn’t correctly flag that an unused method receiver is used when a _ is present as a receiver in methods, for example, func (_ *Foo). It is recommended to omit this receiver when unused, as it is not required.
  • CS-P1001: We were incorrectly flagging the invocation of GC-related methods in protected virtual void Dispose(bool disposing). We’ve fixed that.
  • CS-W1022: We’ve fixed an issue where declared and initialized variables in separate and succeeding lines were flagged as uninitialized.
  • CS-R1071: We’ve fixed an issue where the Analyzer incorrectly recommended replacing numeric literals, such as 3.14 and 6.28 with values from the Math class even when suffixed with suffixes such as m.
  • SC-R1015: We’ve fixed an issue where the if-else chain was not adequately evaluated, thereby erroneously marking the else in else if in an if-else chain as redundant.
  • JS-0057: We’ve fixed an issue where we were incorrectly flagging empty functions with comments inside them. Functions intentionally left empty with comment(s) inside them should not be flagged as empty.
  • JS-0394: We’ve fixed an issue where we were incorrectly flagging Nuxt’s NavLink component if it had className prop.
  • JS-0122: We’ve fixed an issue where we were incorrectly flagging TypeScript interface properties that share the same name with JS global variables.
  • JS-0330: We’ve fixed an issue where we were incorrectly flagging TypeScript code where the type of the argument passed to setTimeout is non-determinable.
  • JS-0242: Destructured object properties are no longer flagged if at least one is non-const.
  • JS-0576: OnPush is the recommended component change detection strategy in Angular. But, we used to incorrectly check for onPush and flag OnPush as incorrect. Additionally, the Autofix™️ for this was incorrect as we used to transform the code to onPush instead of OnPush. We’ve fixed these.
  • JS-D023: We’ve fixed an issue where we were incorrectly flagging code that passed any non-literal argument to child_process. We now check for cases where tainted data is passed to child_process methods.
  • BAN-B413: We’ve fixed an issue where we were incorrectly flagging the PyCryptodome library as insecure. pycryptodome is a library with an API compatible with pycrypto, but with no vulnerabilities.
  • CS-R1022: We incorrectly recommended users to remove default: break;even when a comment or pragma was associated with it. We now only recommend this issue if there are no associated user comments.
Previous
Next