Wrong ref in the metadata.json file?

[jtpio]

Description

Attempting to make a JupyterLab release with the following input:

Produces the following metadata.json file:

{
  "version_spec": "next",
  "ref": "refs/heads/main",
  "branch": "master",
  "repo": "jupyterlab/jupyterlab",
  "since": "v4.0.0a29",
  "since_last_stable": false,
  "version": "4.0.0a30",
  "post_version_spec": "",
  "post_version_message": "Bumped version to {post_version}",
  "expected_sha": "b570b52597d85dba63816c24d1909bd70eaeb57b"
}

With ref pointing to refs/heads/main.

Reproduce

JupyterLab is still on master for its default branch so a reference to main looks odd.

Expected behavior

Ref should probably point to master.

Context

[jtpio]

The "Publish Release" workflow is then failing with the following issue:

ensure-sha




--------------------------------------------------
Using env value for ref: 'refs/heads/main'
Using env value for branch: 'master'
Using env value for repo: 'jupyterlab/jupyterlab'
Using env value for dry_run: 'false'
Using env value for expected_sha: 'b570b52597d85dba63816c24d1909bd70eaeb57b'
Using default value for help: 'False'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Ensuring sha...
COMMAND: git remote -v
origin	***github.com/jupyterlab/jupyterlab.git (fetch) [blob:none]
origin	***github.com/jupyterlab/jupyterlab.git (push)
COMMAND: git fetch origin master
From https://github.com/jupyterlab/jupyterlab
 * branch                master     -> FETCH_HEAD
COMMAND: git rev-parse origin/master
aeb646d7853eb1c4aa2033086a2c0e7cc6792841
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.10.7/x64/bin/jupyter-releaser", line 8, in <module>
    sys.exit(main())
  File "/opt/hostedtoolcache/Python/3.10.7/x64/lib/python3.10/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.10.7/x64/lib/python3.10/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/opt/hostedtoolcache/Python/3.10.7/x64/lib/python3.10/site-packages/jupyter_releaser/cli.py", line 121, in invoke
    super().invoke(ctx)
  File "/opt/hostedtoolcache/Python/3.10.7/x64/lib/python3.10/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/opt/hostedtoolcache/Python/3.10.7/x64/lib/python3.10/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/opt/hostedtoolcache/Python/3.10.7/x64/lib/python3.10/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.10.7/x64/lib/python3.10/site-packages/jupyter_releaser/cli.py", line 660, in ensure_sha
    util.ensure_sha(dry_run, expected_sha, branch)
  File "/opt/hostedtoolcache/Python/3.10.7/x64/lib/python3.10/site-packages/jupyter_releaser/util.py", line 653, in ensure_sha
    raise RuntimeError(msg)
RuntimeError: master current sha aeb646d7853eb1c4aa2033086a2c0e7cc6792841 is not equal to expected sha b570b52597d85dba63816c24d1909bd70eaeb57b

https://github.com/jtpio/jupyter_releaser/actions/runs/3228547001/jobs/5284782784

[blink1073]

Ah, it looks like there is a commit made before ensure_sha is called, probably in one of the hooks

[blink1073]

For now you can run the v1 workflows

[blink1073]

I made a 1.x branch from the v1 tag that you can use in the workflow runs.

[blink1073]

You'll need to add that branch to your fork

[jtpio]

Ah, it looks like there is a commit made before ensure_sha is called, probably in one of the hooks

Right: https://github.com/jupyterlab/jupyterlab/blob/aeb646d7853eb1c4aa2033086a2c0e7cc6792841/pyproject.toml#L226-L230

Probably these could be updated when we adopt the releaser v2 there.

[jtpio]

You'll need to add that branch to your fork

Is there a way to show workflows from that branch in the Actions tab?

Otherwise probably that means making 1.x the default branch of the fork so the previous workflows show up there?

[blink1073]

Ah, yeah, you'll probably need to make 1.x the default

[jtpio]

Thanks, making 1.x the default does shows the previous workflows 👍

Ah, it looks like there is a commit made before ensure_sha is called, probably in one of the hooks

Do you think extra commits that are created during the process should be supported? Or should projects not try to commit anything and let the releaser do it?

[blink1073]

We'd have to do something similar to RH_SINCE, capture it at the beginning of the run.

[blink1073]

I think if you change the JupyterLab hook to use git add it should be okay.

[blink1073]

Closing as fixed by jupyterlab/jupyterlab#13322

[jtpio]

Closing as fixed by jupyterlab/jupyterlab#13322

Just tried to make a new 4.0 pre-release for JupyterLab (which includes jupyterlab/jupyterlab#13322) with the v2 workflows and got the same issue: https://github.com/jtpio/jupyter_releaser/actions/runs/3495078160/jobs/5851451020

[jtpio]

A workaround to publish the release for now is to add ensure-sha to the list of steps to skip.

[jtpio]

I'll open an issue on the JupyterLab repo to track this.