cmd/cue: mod publish includes unstable output for ~same module

[myitcv]

What version of CUE are you using (cue version)?

$ cue version
cue version v0.9.0-alpha.4

go version go1.22.2
      -buildmode exe
       -compiler gc
       -trimpath true
     CGO_ENABLED 0
          GOARCH arm64
            GOOS linux
cue.lang.version v0.9.0

Does this issue reproduce with the latest release?

The latest pre-release, yes.

What did you do?

https://review.gerrithub.io/c/cue-lang/cuelang.org/+/1194141 was the change that upgraded https://cuelang.org to v0.9.0-alpha.4. Within that CL however we were forced into making a couple of changes like:

https://review.gerrithub.io/c/cue-lang/cuelang.org/+/1194141/6/content/docs/tutorial/publishing-modules-to-the-central-registry/en.md

because the output of cue mod publish was no longer stable.

https://review.gerrithub.io/c/cue-lang/cuelang.org/+/1194143/1 and the associated trybot failure demonstrates the issue. After a re-run of the preprocessor skipping the cache we get the following diffs:

diff --git a/hugo/content/en/docs/tutorial/publishing-modules-to-the-central-registry/index.md b/hugo/content/en/docs/tutorial/publishing-modules-to-the-central-registry/index.md
index aa2c3326..a1cd1745 100644
--- a/hugo/content/en/docs/tutorial/publishing-modules-to-the-central-registry/index.md
+++ b/hugo/content/en/docs/tutorial/publishing-modules-to-the-central-registry/index.md
@@ -201,7 +201,7 @@ module.
 Publish the first version of this module:
 ```text { title="TERMINAL" codeToCopy="Y3VlIG1vZCBwdWJsaXNoIHYwLjAuMQ==" }
 $ cue mod publish v0.0.1
-published github.com/cueckoo/frostyconfig@v0.0.1 to registry.cue.works/github.com/cueckoo/frostyconfig:v0.0.1@sha256:a9e174a2e17e244[61](https://github.com/cue-lang/cuelang.org-trybot/actions/runs/8912297589/job/24475454801#step:40:62)ae16db9c5d07a749c24fa827fecc575990ef72060fa42ee
+published github.com/cueckoo/frostyconfig@v0.0.1 to registry.cue.works/github.com/cueckoo/frostyconfig:v0.0.1@sha256:06b8016ebe451ebb21e6d1ca28361bd066d2ad423149f8d51b7b98c92f397c10
...

This indicates that the output of cue mod publish is not stable.

What did you expect to see?

Stable output from cue mod publish.

What did you see instead?

Per above. Which indicates that cue mod publish is not itself repeatable.

The thing to note in this example is that we are using git as a source. When the preprocessor re-runs a guide, it does so with a fresh git repo. Which means the commit that results from the re-running of the guide will ~never have the same commit ref. So it makes sense that it the output from cue mod publish is a function of the metadata including that commit hash then it would change.

I guess part of the issue here is that it's not clear to me we want/need to be outputting this level of detail by default. It's noise at best.

[myitcv]

Ok so here is something that confirms we appear, at least from the output, that the same git commit is stable:

env HOME=$WORK/.home
env CUE_EXPERIMENT=modules

mkdir $HOME
cd example

exec git config --global user.email "cueckoo@cueckoo.land"
exec git config --global user.name cueckoo

# Start two registries for good measure
exec cue mod registry localhost:5000 &
exec cue mod registry localhost:6000 &
exec sleep 1

exec git init -q
exec cue mod init --source=git glacial-tech.example/frostyconfig@v0

exec cue mod tidy

exec git add -A
exec git commit -q -m 'Initial commit'
exec git status
exec ls -la

env CUE_REGISTRY=localhost:5000/cuemodules
exec cue mod publish v0.0.1
cp stdout $WORK/reg1.golden

env CUE_REGISTRY=localhost:6000/cuemodules
exec cue mod publish v0.0.1
cmp stdout $WORK/reg1.golden

-- example/config.cue --
package frostyconfig

// #Config defines the schema for the FrostyApp configuration.
#Config: {
	// appName defines the name of the application.
	appName!: string
	// port holds the port number the application listens on.
	port!: int
	// debug holds whether to enable debug mode.
	debug?: bool
	// features holds optional feature settings
	features?: {
		// logging enables or disables logging.
		logging?: bool
		// analytics enables or disables analytics.
		analytics?: bool
	}
}

Notice the output (on a local run):

> cmp stdout $WORK/reg1.golden
--- stdout
+++ $WORK/reg1.golden
@@ -1,1 +0,0 @@
-published glacial-tech.example/frostyconfig@v0.0.1 to localhost:6000/cuemodules/glacial-tech.example/frostyconfig:v0.0.1@sha256:09bdcf220178e0722dd6fc5b5e02e803edc73ad5a1b3a96a01203acc5a0691f1
@@ -0,0 +1,1 @@
+published glacial-tech.example/frostyconfig@v0.0.1 to localhost:5000/cuemodules/glacial-tech.example/frostyconfig:v0.0.1@sha256:09bdcf220178e0722dd6fc5b5e02e803edc73ad5a1b3a96a01203acc5a0691f1

FAIL: /tmp/testscript3671823808/repro.txtar/script.txtar:31: stdout and $WORK/reg1.golden differ

The diff appears in the registry, but the sha256 is stable. So modulo checking some further details, let's assume the contents published by cue mod publish are fine.

So this I think shifts this issue to what we output when running cue mod publish:

• Do we need/want to publish anything on a successful publish?
• Is the sha256 a relevant detail for me when I publish? It feels noisy by default to emit it.
• I thought cue mod resolve was introduced precisely to tell us which registry we will "target" with a publish - do we need to emit this too?

My hunch is that we can/should be silent on success, unless we have -v or similar.