Skip to content

Code scanning with CodeQL improves support for Java codebases that use Project Lombok

Code scanning with CodeQL now supports Java codebases that use Project Lombok. Previously, code scanning users were able to scan Java applications that contained Lombok code, but all the contents of files containing Lombok code were either skipped or users had to apply a workaround to prepare the applications for scanning. The improved support means that code with Lombok features will be automatically scanned without requiring any workaround.

As more code will now be analyzed by the CodeQL engine, we can establish more accurate data flow (or lack thereof) through Lombok code. This might have an impact on the number of alerts produced by a scan. The most common scenario is that additional alerts appear in the newly-analyzed code. Conversely, there is a very small chance that some existing alerts are closed.

Improved support for Java applications built using Lombok is available for code scanning users on GitHub.com starting today and GitHub Enterprise Server users starting with 3.11. CodeQL CLI will provide out of the box support starting with the upcoming version 2.14.4. Security researchers can set up the CodeQL CLI and VS Code extension by following these instructions.

Repository rules allow you to easily add scalable protections for branches and tags on your repositories. This feature was recently made generally available, and GitHub Desktop 3.3 now adds support for repository rules in the form of preemptive warnings and errors if your work fails a rule configured by an administrator of your repository. These rules can fail when commits are pushed to GitHub, which may not be ideal if you queue up multiple commits before pushing. Advanced warning allows you to make changes before committing, saving you time and frustration.

Repository rules

Administrators can configure many different repository rules that apply to branches or tags. If a commit fails any of them, you won’t be able to push it to GitHub. This can be frustrating if you have multiple commits queued up, because the whole push will fail and you may have to perform a rebase to fix the failed commits. GitHub Desktop will now preemptively warn you if a commit you’re working on will fail a rule when you eventually try to push it. These warnings happen in several ways.

Branch creation

Specific branch names may be disallowed. You’ll now see an error if you try to create a branch that isn’t allowed.

GitHub Desktop’s “Create a branch” dialog showing a disallowed branch name error

Metadata rules

GitHub Enterprise Cloud customers can utilize metadata rules that require certain fields to conform to specific values. One example being commit messages, which can be required to match a specific string or a regex pattern. These metadata rules are fully supported in GitHub Desktop 3.3.

GitHub Desktop’s commit message area, showing an error for a commit message rule failure

Additional rules

Certain rules have remediations that aren’t supported by GitHub Desktop, such as requiring status checks to pass. These rules are bundled into a catch-all error message above the commit button.

GitHub Desktop’s commit message area, showing a generic error for a failed repository rule

Bypassing

Administrators can allow certain apps, roles, or teams to bypass rulesets. If you can bypass rules, the guidance shown is in the form of warnings instead errors, to let you know to be extra careful.

GitHub Desktop’s commit message area, showing bypass warnings for a commit message rule and another rule

Shout out to our open source contributors

GitHub Desktop is proud to be an open source project and represents both GitHub and the open source community. Thanks to @le0pard for creating the RE2JS library being used for repository rules regex matching.

Automatic updates will roll out progressively, or you can download the latest GitHub Desktop here.

See more

Enterprise Managed User namespace repositories were previously able to use GitHub-hosted Actions runners outside of the owning enterprise's entitlements. This was not an intentional configuration. Today we have disabled the ability for EMU user namespace repositories to use GitHub-hosted runners.

For customers using inner source workflows we recommend forking from an organization owned repository into your user namespace. You may then open a pull request back to the upstream repository and actions workflows will run as usual within the context of that organization and enterprise.

Learn more about enabling private repositories to run actions workflows from forks.

See more