Version Labeling incorrect?

fronobulax · Oct 27, 2021

See https://kolmafia.us/threads/build-25813-breaks-all-scripts.26732/

I allegedly ran the same version and some of the same scripts. Could be a Windows thing but I wonder about labels.

I selected my main branch, got updates from the origin and then did gradlew shadowjar. That gave me r25813.

I just tried again and got r25814 which seems reasonable.

But I switched to an unpublished local branch and then built. I expected r25814M but also built r25814,

I didn't do anything to confirm that the r25814 jar files were identical but I am concerned that either I don't understand version naming or it is not being done as I expect.

Comments?

fronobulax · Oct 29, 2021

So I was on a branch and built -M. I wish I understood this well enough to trust it or fix it

MCroft · Oct 29, 2021

When you start a build based on a branch, you get branch info in the About pane and also in the CLI:

Rich (BB code):

> Task :runShadow

KoLmafia r25820-M
Build outfits-and-tattoos fd9ff10856e45a5fb1d88201e1d77958f122d4a6 16.0.1 (Azul Systems, Inc. 16.0.1+9) Mac OS X x86_64 10.16

Currently Running on Mac OS X
Local Directory is /Users/mcroft/Library/Application Support/KoLmafia
Using Java 16.0.1

as opposed to...

Rich (BB code):

> Task :runShadow


KoLmafia r25820-M
Build main-67f7730-M 16.0.1 (Azul Systems, Inc. 16.0.1+9) Mac OS X x86_64 10.16

fronobulax · Oct 29, 2021

Maybe on a Mac...

C:\KoLmafia>gradlew shadowjar

> Configure project :
[versioning] WARNING - the working copy has unstaged or uncommitted changes.

> Task :getRevision

Revision: 25821-M

BUILD SUCCESSFUL in 17s
6 actionable tasks: 3 executed, 3 up-to-date
C:\KoLmafia>

Different branch, no uncommitted changes

C:\KoLmafia>gradlew shadowjar

> Task :compileJava
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :getRevision

Revision: 25821

BUILD SUCCESSFUL in 37s
6 actionable tasks: 5 executed, 1 up-to-date
C:\KoLmafia>

Main

C:\KoLmafia>gradlew clean

BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executed
C:\KoLmafia>gradlew shadowjar

> Task :getRevision

Revision: 25821

BUILD SUCCESSFUL in 12s
6 actionable tasks: 3 executed, 3 from cache
C:\KoLmafia>

Hypothesis - the M is only appended when there are local changes that have not been committed to a branch.

Problem - 25821 is the revision when I build from my main or a local branch pulled from a PR. Not going to make for good configuration management or replicating user problems locally.

Observation - Running on a Mac emits version and branch info that goes to the console on a Mac but not on Windows.

AFAIK I have no local changes or settings that affect gradle but since there is a .gradle directory in the user directory maybe an old install (since removed) or IntelliJ is "leaking" settings.

MCroft · Oct 29, 2021

fronobulax said:
Maybe on a Mac...

Should be easy to debug. KoLmafia.java's main method starts on line 190:

Java:

  /**
   * The main method. Currently, it instantiates a single instance of the <code>KoLmafiaGUI</code>.
   */
  public static final void main(final String[] args) {
    System.out.println();
    System.out.println(StaticEntity.getVersion());
    System.out.println(StaticEntity.getBuildInfo());
    System.out.println();
    System.out.println("Currently Running on " + System.getProperty("os.name"));

    try {
      System.out.println("Local Directory is " + KoLConstants.ROOT_LOCATION.getCanonicalPath());

    } catch (IOException e) {
      System.out.println(e.getMessage() + " while trying to determine local directory.");
    }
    System.out.println("Using Java " + System.getProperty("java.version"));
    System.out.println();

StaticEntity.getBuildInfo() calls StaticEntity.getAttributes(), which reads META-INF/MANIFEST.MF

Through sheerest luck, I had already unzipped a recent shadowJar:

Michaels-MBP:META-INF mcroft$ cat MANIFEST.MF
Manifest-Version: 1.0
Main-Class: net.sourceforge.kolmafia.KoLmafia
Build-Revision: 25816
Build-Branch: additional_fix_for_afterlife
Build-Build: 0759421
Build-Dirty: true
Build-Jdk: 16.0.1 (Azul Systems, Inc. 16.0.1+9)
Build-OS: Mac OS X x86_64 10.16

which leads me to this command (albeit a different run on a different branch):

Michaels-MBP:kolmafia mcroft$ ./gradlew versionDisplay
> Configure project :
[versioning] WARNING - the working copy has unstaged or uncommitted changes.
> Task :versionDisplay
[version] scm = git
[version] branch = main
[version] branchType = main
[version] branchId = main
[version] commit = 67f77308473d2b49561010ea01e6bcc5b465dc38
[version] full = main-67f7730-dirty
[version] base =
[version] build = 67f7730
[version] display = main-67f7730-dirty
[version] tag =
[version] lastTag = r25820
[version] dirty = true
BUILD SUCCESSFUL in 820ms

Which leads in a very roundabout way to the question "What does gradlew.bat versionDisplay tell you about your git directory?

fronobulax · Oct 29, 2021

On a branch

C:\KoLmafia>gradlew versiondisplay

> Task :versionDisplay
[version] scm = git
[version] branch = preferences
[version] branchType = preferences
[version] branchId = preferences
[version] commit = 2c09adaa66808855fe39b2b44e7033ab26d5695c
[version] full = preferences-2c09ada
[version] base =
[version] build = 2c09ada
[version] display = preferences-2c09ada
[version] tag =
[version] lastTag = r25822
[version] dirty = false

BUILD SUCCESSFUL in 1s
1 actionable task: 1 executed
C:\KoLmafia>

On main

> Task :versionDisplay
[version] scm = git
[version] branch = main
[version] branchType = main
[version] branchId = main
[version] commit = 0713b22f218f67f56d9cf25cb517d7817e3c7998
[version] full = main-0713b22
[version] base =
[version] build = 0713b22
[version] display = main-0713b22
[version] tag =
[version] lastTag = r25822
[version] dirty = false

BUILD SUCCESSFUL in 1s
1 actionable task: 1 executed
C:\KoLmafia>

heeheehee · Oct 30, 2021

I'm about 90% sure that the M indicator refers to whether you have uncommitted changes or not, rather than whether you have non-upstream changes or not.

MCroft · Oct 30, 2021

heeheehee said:
I'm about 90% sure that the M indicator refers to whether you have uncommitted changes or not, rather than whether you have non-upstream changes or not.

This is what I was reading. It's complex, but it's related to the work-tree, not the working directory.

Does git "dirty" mean files not staged, or not committed? (glossary conflict)

https://www.kernel.org/pub/software/scm/git/docs/gitglossary.html#def_dirty A working tree is said to be "dirty" if it contains modifications which have not been committed to the current branch. h...

stackoverflow.com

I think I agree with the answer that says "A working tree is said to be "dirty" if it contains modifications which have not been committed to the current branch."

So if you are on branch preferences and forcibly merge from main, you're dirty, but if you check out main afterwards, you're clean. This may be wrong as I am not really up-to-speed on working dirs vs. work-trees.

MCroft · Oct 30, 2021

fronobulax said:
C:\KoLmafia>gradlew shadowjar

> Configure project :
[versioning] WARNING - the working copy has unstaged or uncommitted changes.

> Task :getRevision

Revision: 25821-M

BUILD SUCCESSFUL in 17s
6 actionable tasks: 3 executed, 3 up-to-date
C:\KoLmafia>

fronobulax said:
[...]

Observation - Running on a Mac emits version and branch info that goes to the console on a Mac but not on Windows.

But you're not running. You're building. That's the difference between gradlew shadowjar and gradlew runshadow. runShadow is the equivalent of gradlew shadowjar && java -jar dist/KoLmafia*.jar

Rich (BB code):

Michaels-MBP:kolmafia mcroft$ ./gradlew tasks
> Configure project :
[versioning] WARNING - the working copy has unstaged or uncommitted changes.
> Task :tasks
------------------------------------------------------------
Tasks runnable from root project 'KoLmafia'
------------------------------------------------------------
Application tasks
-----------------
run - Runs this project as a JVM application
runShadow - Runs this project as a JVM application using the shadow jar
startShadowScripts - Creates OS specific scripts to run the project as a JVM application using the shadow jar

fronobulax · Oct 30, 2021

OK. M doesn't mean what I want it to mean but I understand it.

I use "run" in many contexts and I thought I was looking at running a build process on a Mac and not actually trying to run KoLmafia.

I have no idea why anyone would choose to use gradlew runshadow

I did it anyway..

C:\KoLmafia>gradlew runshadow

> Task :runShadow

KoLmafia r25822
Build preferences-5b00322 17 (Oracle Corporation 17+35-LTS-2724) Windows 10 amd64 10.0

Currently Running on Windows 10
Local Directory is C:\KoLmafia
Using Java 17

<===========--> 90% EXECUTING [3m 26s]
> :runShadow

Tangentially runshadow brought up the preferences window on top of the main window which is a very good reason for me not to use the command. It also is not using the same look and feel and main image as my normal run procedure. It is probably because my tree looks like C:\KoLmafia\dist and the default directory for gradle is C:\KoLmafia but all my user files are in or below C:\KoLmafia\dist. I have trained IntelliJ to use the right home but I have no interest in teaching gradle. (The separation comes from over a decade of being able to build on only one machine but being able to run on two different machines and using Dropbox to synch only files needed to run, including the jar).

Bottom line, though is what I had hoped for when we discussed revision numbering is not happening. I would have dragged my feet harder on the switch if I had expected this :-(

The reason it is important is that if user reports a problem with rxyzzy and I want to try and replicate it on my system I don't know how to do that with confidence. Indeed if rxyzzy is the latest on main I can build something labelled rxyzzy in several different ways. Which one matches the user? The situation gets messier if then user is also building locally.

I can build the same version number in several different ways by switching branches as long as there are no uncommitted changes.

So our efforts to replicate the unique version numbers provided by SVN aren't working as expected.

Do we

Kludge/fix the current revision numbers to restore uniqueness with respect to the generating code?
Abandon a revision number and just use a git generated tag even thought it is a human unfriendly string?
Understand that the revision number only has meaning for builds released on and downloaded from GitHub?
Require users to reproduce incidents on the latest downloaded build if significant support is needed?
???

I admit to trying to apply a Configuration Management model that works real well with SVN to Git and that may be the problem. How would Git do it and should we talk about switching and managing expectations?

heeheehee · Oct 30, 2021

fronobulax said:
The reason it is important is that if user reports a problem with rxyzzy and I want to try and replicate it on my system I don't know how to do that with confidence. Indeed if rxyzzy is the latest on main I can build something labelled rxyzzy in several different ways. Which one matches the user? The situation gets messier if then user is also building locally.

We automatically create tags for each revision.

I would do something like:

Code:

$ git switch --detach tags/25801
$ ./gradlew clean shadowJar
...

Aspirationally, I'd like to expand our notion of dirty (modified) to include the presence of non-upstream commits: namely, if HEAD and origin/main are different commits. I haven't spent the time to figure out how we'd do that, though.

fronobulax · Oct 30, 2021

OK. If I have a version number then I can find the corresponding tag and grab the source.

That doesn't address local builds. In particular someone reported a problem in a version and I reported I could not reproduce it. It now appears that was the result of my local build off of a committed branch. Maybe all local builds unless they are build from a fully committed "main" get marked with M?

Thanks.

heeheehee · Oct 30, 2021

Anyways. Frono noticed that I started https://github.com/kolmafia/kolmafia/pull/169 to address this and a related issue that I observed with our revision labeling.

heeheehee · Oct 30, 2021

This is now merged as r25825, let me know if that works as you expect it to (e.g. by merging that into whichever branch you're working on)

fronobulax · Oct 30, 2021

r25825 is the latest tag.

I have a local branch main, which I think is whatever is the main on githib.

I have a branch, preferences which I think is the same as main with changes captured to the branch and published as a PR.

I have a branch, CodeQL which I think is the same as main with changes captured to the branch but not published as a PR.

The changes in preferences and CodeQL are independent.

I switched to main, built a jar, to CodeQL built a jar and then preferences and built a jar. Each invocation of gradlew shadowjar was on a different branch.

C:\KoLmafia>gradlew shadowjar

> Task :getRevision

Revision: 25825

BUILD SUCCESSFUL in 9s
6 actionable tasks: 3 executed, 2 from cache, 1 up-to-date
C:\KoLmafia>gradlew shadowjar

> Task :getRevision

Revision: 25825-M

BUILD SUCCESSFUL in 8s
6 actionable tasks: 2 executed, 2 from cache, 2 up-to-date
C:\KoLmafia>gradlew shadowjar

> Task :getRevision

Revision: 25825

BUILD SUCCESSFUL in 9s
6 actionable tasks: 3 executed, 2 from cache, 1 up-to-date
C:\KoLmafia>

I would have expected the third invocation to have produced 25825-M

The About page in the last of the three jars does say Build preferences-5b00322. I think it might be helpful if the build portion of shadowjar emitted that string or similar.

heeheehee · Oct 31, 2021

Do these branches contain r25625? That is, did you create the branches from that point, and/or merge in origin/main?

For reference, I checked out origin/preferences, built it, got r25625. I then merged in origin/main and got r25625-M.

Unfortunately, our gradle setup isn't magically able to pick up changes that you haven't pulled in.

fronobulax · Oct 31, 2021

heeheehee said:
Do these branches contain r25625? That is, did you create the branches from that point, and/or merge in origin/main?

For reference, I checked out origin/preferences, built it, got r25625. I then merged in origin/main and got r25625-M.

Unfortunately, our gradle setup isn't magically able to pick up changes that you haven't pulled in.

I am a touch confused but I think the answer is maybe not. I will withhold all of my further observations until I am certain that the branch includes the gradle changes. Thanks.

Version Labeling incorrect?

fronobulax

Developer

fronobulax

Developer

MCroft

Developer

fronobulax

Developer

MCroft

Developer

fronobulax

Developer

heeheehee

Developer

MCroft

Developer

Does git "dirty" mean files not staged, or not committed? (glossary conflict)

MCroft

Developer

fronobulax

Developer

heeheehee

Developer

fronobulax

Developer

heeheehee

Developer

heeheehee

Developer

fronobulax

Developer

heeheehee

Developer

fronobulax

Developer