Add audit log for successful LK version changes - #7943
Conversation
labkey-susanh
left a comment
labkey-susanh
left a comment
There was a problem hiding this comment.
I have done no testing of this.
|
|
||
| private static boolean isSnapshot(String version) | ||
| { | ||
| return StringUtils.containsIgnoreCase(version, "SNAPSHOT"); |
There was a problem hiding this comment.
Probably this could be endsWith for -SNAPSHOT, or contains with -SNAPSHOT, but not a big deal.
There was a problem hiding this comment.
Switched to endsWith.
| @Test | ||
| public void testDowngrade() | ||
| { | ||
| assertEquals(ChangeType.Downgrade, determineChangeType("26.9.0", BUILD_1, "26.7.1", BUILD_2, false)); |
There was a problem hiding this comment.
Perhaps add a check for 26.10.1 vs. 26.10.0 (patch version change only) and 26.10.x vs 26.9.y (because string comparison would say it's larger).
| _minor = _minor / 10; | ||
| if (_minor > 9 || _minor < 0) | ||
| throw new IllegalStateException("Bad minor version: " + _minor); | ||
| // Temporary fix for SQL Server 2008 R2 (10.50.1600.1). TODO: Support two-digit version ints (MMmm) |
There was a problem hiding this comment.
Not part of this update, of course, but this is weird. Is it still needed as a "temporary" fix?
There was a problem hiding this comment.
It's temporary as of 2011. getVersionInt() seems like a bad idea to me and I'd like to get rid of it, but I didn't want to wade into the code that figures out which SqlDialect variant to use for the target DB. Adding VersionNumber.compareTo() will make that refactor easier but I think it should be separate.
| } | ||
|
|
||
| return _major * 10 + _minor; | ||
| /** getVersionInt() used to divide the minor version in place, which would corrupt later comparisons */ |
There was a problem hiding this comment.
This "used to" comment will not be relevant past this PR.
Co-authored-by: Susan Hert <susanh@labkey.com>
Co-authored-by: Susan Hert <susanh@labkey.com>
| return _newInstall; | ||
| } | ||
|
|
||
| /** Did any module, including core, run schema scripts during this startup? */ |
There was a problem hiding this comment.
There are cases where schema versions get bumped without running SQL scripts, but that's a nit.
#### Rationale In order to understand when their servers were upgraded, we want to expose a new audit table that tracks deployments/startups with new builds. This PR adds the audit log query name to the app admin settings "Audit Log" page: <img width="1457" height="494" alt="Screenshot 2026-08-19 at 3 54 41 PM" src="https://github.com/user-attachments/assets/7a35adde-a332-47aa-af13-385f78f05e01" /> #### Related Pull Requests - LabKey/platform#7943 - #2063 - LabKey/limsModules#2418 #### Changes - Add audit log for successful LK version changes --------- Co-authored-by: labkey-jeckels <jeckels@labkey.com>
## Rationale In order to understand when their servers were upgraded, we want to expose a new audit table that tracks deployments/startups with new builds. ## Related Pull Requests - LabKey/platform#7943 ## Changes - New upgrade test to ensure that we write entries during bootstrap and upgrade --------- Co-authored-by: cnathe <cnathe@labkey.com>
4 participants
Rationale
In order to understand when their servers were upgraded, we want to expose a new audit table that tracks deployments/startups with new builds.
Related Pull Requests
Changes