You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
Changed
The Library has a Version column right after the rule's name. It shows the version a shipped rule runs (1.0.0 for RuleBeat Core, the upstream commit date such as 2026-06-08 for APRL), and a New chip when a newer version is recorded. The Version filter and the "New version" chip beside the rule name are gone. A rule's Rule version panel is now one list of every recorded version, newest first, instead of a dropdown and a collapsible history. Select a version to review it, and an admin can switch to an older or newer one.
Rules left on "Before versioning" now run their pack's shipped version, so the next scan may flag different resources. On the first start after this upgrade, a shipped rule that an earlier release kept on its own stored definition, or that was stored with no version and differs from what ships, takes the shipped definition and version, enabled or not. The "Before versioning" version is deleted. A rule no pack ships any more keeps its stored definition, stays retired and shows no version. A custom rule copied from a rule on "Before versioning" now reads "Duplicated from" with no newer-version note. Rule ids, enabled state, tags, findings and suppressions are unchanged.
Em dashes are gone from the code comments, test titles, CI and script log lines and engineering docs, and a test now fails on any new one anywhere in the repo. No behaviour changes.
Scans no longer store a full copy of their findings, which was most of the database on a large history. Run History already reads each run's short per-finding records, so nothing on screen changes. On its first start this upgrade empties the copy each past scan stored, one scan at a time, keeping every record. A database that still needs the one-time findings or posture trend history rebuilt gets it from those copies first, and has them emptied on the start after. A past scan whose records could not be made at an earlier upgrade keeps its copy. On SQLite the file does not shrink without a VACUUM, but the space is reused by new data. Going back to 0.9.0 loses nothing, but rolling back further, to 0.8.x or earlier, shows every run in Run History with no findings, including runs made after this upgrade.
The messages RuleBeat shows no longer use em dashes. Error messages, audit log entries, server log lines and on-screen help and warning text are now plain sentences with the same meaning, an empty value now shows a hyphen, and a dashboard's browser tab title reads the dashboard name, then a dot, then RuleBeat.
Fixed
The APRL pack shipped two rules whose query was only an upstream placeholder comment, "Ensure Resource Group and its Resources are located in the same Region" and "If using single-instance VMs all OS and data disks must be Premium SSD or Ultra Disk". They could never pass or find anything, and the Library listed them. They no longer ship, so the pack holds 141 rules and the out-of-the-box total is 157 checks. On the first start after this upgrade an installed copy is marked retired and otherwise left as it was: an enabled copy stays enabled and keeps failing on its placeholder query, and its tags, findings and suppressions are kept.
Most APRL rules ran another recommendation's query, so their findings could name a problem the resource does not have. Each rule now runs its own recommendation's query. On the first start after this upgrade, the installed APRL rules that run a wrong query are corrected in place, enabled ones included, and the findings those queries produced are removed, open and fixed alike. A rule's enabled state, tags, version and suppressions are kept, and posture history and Run History are not rewritten. The next scan of a corrected rule starts clean. An install upgrading from before 0.8.0 keeps an enabled APRL rule on its stored query, as for any rule that predates versions.
On PostgreSQL, a database read that failed while past scans were being converted into records at startup undid every other upgrade step of that start. Now a failed read costs only what it was reading: the whole conversion if it was the list of scans to convert, or one scan if it was that scan's stored findings. The failure is logged, the other steps are kept, the app starts, and the next start tries the conversion again.
When rebuilding the finding history at startup fails for one category, that category keeps its stored findings and is tried again on every start, instead of the rebuild being marked done. Categories already rebuilt are not replayed, and the stored findings are emptied only once every category is rebuilt or had nothing to rebuild. A category that was scanned since the failed start is not rebuilt, so its newer findings stay as that scan left them.
The New Rule form let you choose neither the rule's kind nor its tags, and the Enabled switch could not be turned off. All three now work, as they already did when editing a custom rule.
The Library listed each rule's tags under the Kind column and its kind under Tags. Each now sits under its own header.
Building the image from a checkout that has run the Demo sent the Demo's saved snapshots, 15 MB each, to Docker with the source. They are now left out. The image itself does not change.