2.3.1.7 release notes

 

2.3.1.7

  • JetBrains has issued patch-level updates for all of their 2023.1+ IDEs to fix a security issue. Please see the linked information for details, but the short version is that the security issue should only affect those using JeBrains' GitHub pull request integration. Nonetheless, I strongly encourage all users update to a JetBrains IDE version with this fix ASAP.
  • More improvements to the recent dependencies-/dependents-based enhancements for Apex unit test execution and code coverage analysis:
    • All transitive dependencies and dependents are now collected at the member-level instead of the file-level. Again, this means that the resulting set of dependencies/dependents should be as small and focused as possible short of performing runtime data flow analysis. When using the new "changed-only" features, this should ultimately mean less time spent waiting for unrelated unit tests to execute and a more focused view of impacted code coverage.
    • Added many more metadata relationships when collecting dependency/dependents of Apex unit tests:
      • Custom labels at the granularity of individual changed labels
      • Custom objects/metadata types/settings and their fields
      • DataWeave scripts
      • Flows
      • Static resources
      • Visualforce pages
      • Profiles and permission sets at the granularity of individual authorization changes
    • Added the following new application-level configuration options so that Apex unit test execution and code coverage analysis behavior can be tuned according to end user preferences:
      • Unit Tests | Deploy only changed files - When enabled alongside Deploy before running unit tests, only files changed in version control are included in the pre-unit test execution deployment. Again, changed files are collected based on transitive dependency/dependent relationships at a fine-grained level. When disabled, all transitive dependencies of the unit test run configuration's test classes/methods are included in the deployment. This option is disabled by default.
      • Code Coverage | When filtering by changes, show ... - Determines which contents are included in the Apex code coverage view when filtering based on version control changes:
        • All - Shows an unfiltered view of all production Apex classes and triggers.
        • Changed (default) - Includes all explicitly changed production Apex classes and triggers.
        • Changed and dependents - Includes all explicitly changed production Apex types and triggers and unchanged production Apex classes and triggers which have a transitive dependency relationship with other changed metadata. Unchanged production Apex classes and triggers list the specific changed transitive dependencies — Apex declarations and/or metadata files — that prompted their inclusion in the view. Note that in larger projects with extensive version control changes, this option can result in lengthy dependency/dependent calculation times when viewing code coverage.

    I had originally thought these changes would make this work feature-complete aside from bug fixes and addressing any metadata dependency/dependent relationship gaps that may be found. However, there are a few related items still rattling around in my head that will likely get near-term attention:
    • I'd like to allow the user to specify a VCS branch against which changes are computed, e.g., main/master/trunk, instead of just changes against the current branch as it is now. That way you'd always be running a proper regression relative to a well-defined baseline allowing for incremental commits to the local working branch. Note that this would likely only support Git (initially?) as the JetBrains plugin SDK doesn't provide a common abstraction atop all VCS providers for diffing branches.
    • For those not working against a version control system (which I strongly discourage!), I'd like to allow the user to create a label in the IDE's Local History and designate that label as the baseline for Changed Only calculations. I'll need to see whether or not the Local History API supports such a use case, though.
    • Files which were changed previously and then were subsequently reverted/rolled back should be included in the next pre-test execution deployment to ensure that the org state is consistent with the project state.
    • Transitive dependency/dependent information is currently cached to ensure that these potentially expensive computations do not have to be performed every single time, but I'd like to see whether there are ways to make those caches even more efficient, particularly in scenarios where dependencies with significant ripple effects are changed resulting in a large subset of the code base as being included in the computed transitive dependent graph.

    Note that if you wish to revert to the prior behavior, you can use some or all of the following configuration to do so:
    • Unit Tests | Deploy before running tests - Disabled
    • Unit Tests | Show 'Run' action for production classes and triggers - Disabled
    • Unit Tests | Show 'Run' action for production invocable members - Disabled
    • Unit Tests | Default to 'Changed Only' - Disabled
    • Code Coverage | When filtering coverage by changes, show - All
    and in your Apex unit test run configurations, disable Changed Only.

    My hope, though, is that most or even all of these options would be enabled in all but the largest projects when making broad-impact changes — either changes to a large number of files or changes to metadata with a large number of transitive dependents (or, of course, both) — in version control. If you do find that you're needing to disable these features, please let me know what might have prompted you to do so — whether behavioral, performance-related, or otherwise — as I'd appreciate the opportunity to address those issues for you and all other affected users.
  • It is now possible to find usages directly from Apex class/interface/enum/trigger files, Visualforce page files, static resource files and bundle directories, and SObject type/field metadata files.
  • Removed support for 2023.2 versions of JetBrains IDEs. This was required to take advantage of a newer feature required for proper dependencies/dependents cache management. Support was going to be dropped very shortly anyway when 2024.2 is released, so it only accelerates that process by perhaps 4-6 weeks. Please make sure you're using 2023.3+ going forward.
  • Other minor/related fixes and improvements.