Skip to content

Repository URL in appendix is no longer substituted - #2129

Open
agahkarakuzu wants to merge 2 commits into
jupyterhub:mainfrom
agahkarakuzu:restore-appendix-formatting
Open

agahkarakuzu wants to merge 2 commits into
jupyterhub:mainfrom
agahkarakuzu:restore-appendix-formatting

Conversation

@agahkarakuzu

Copy link
Copy Markdown
  • I am the author of this work
  • Bug fix (non-breaking change which fixes an issue)

Problem

I run a few public BinderHubs (https://terrarium.evidencepub.io, https://live.evidencepub.io). Recently, I switched my registry (https://registry.evidencepub.io) to zot as part of an infrastructure migration, and while I was at it, I wanted to use BuildExecutor.appendix to stamp OCI labels onto built images, so that it is more aligned with the spirit of " reproducible publishing":

LABEL org.opencontainers.image.source="{repo_url}"
LABEL org.opencontainers.image.url="{binder_url}"

After a build I went looking for those labels in my registry and found them set to the literal strings. The build log confirms:

Step 51/57 : LABEL org.opencontainers.image.title="{repo_url}"

Why?

BinderHub.appendix documents the value as a string template:

This should be a Python string template. It will be formatted with at least the following names available: binder_url, repo_url.

and examples/appendix/binderhub_config.py still depends on that:

ENV BINDER_URL={binder_url}
ENV REPO_URL={repo_url}

But nothing really formats it. build.py hands the value straight to repo2docker:

if self.appendix:
    r2d_options.extend(["--appendix", self.appendix])

Tracing it back, the formatting used to live in builder.py:

appendix = self.settings['appendix'].format(
    binder_url=self.binder_launch_host + self.binder_request,
    persistent_binder_url=...,
    repo_url=repo_url,
    ref_url=self.ref_url,
)

Relevance

#1518 moved build parameters to traitlets and left that line commented out on the new code path.Later on, 451059c deleted the commented line as dead code.

How can this PR be tested?

I have not added an automated test, but this reproduces in a couple of minutes with the local dev config, I ran it with enable_api_only_mode:

Adding to binderhub_config.py:

c.BinderHub.build_class = LocalRepo2dockerBuild
c.BinderHub.use_registry = False
c.BinderHub.enable_api_only_mode = True
c.BuildExecutor.appendix = 'LABEL binder.repo="{repo_url}"\nLABEL binder.url="{binder_url}"'

Then:

curl -N -H 'Accept: text/event-stream' \
  'http://localhost:8585/build/gh/binder-examples/requirements/master?build_only=true'
docker inspect <built image> --format '{{json .Config.Labels}}'

Before:

binder.repo = '{repo_url}'
binder.url  = '{binder_url}'

After:

binder.repo = 'https://github.com/binder-examples/requirements'
binder.url  = 'http://localhost:8585/v2/gh/binder-examples/requirements/HEAD'    

Note: use a repo that does NOT contain a Dockerfile. I realized that repo2docker only supports the appendix in the template-generating buildpacks...

I know @rgaiacs is working hard to make it all wasm ready, but we still rely heavily on Binderhub and containers :)

Thank you so much!

@rgaiacs

rgaiacs commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

Hi @agahkarakuzu,

Thanks for the pull request.

I was thinking, why

LABEL org.opencontainers.image.source="{repo_url}"
LABEL org.opencontainers.image.url="{binder_url}"

could not be the default?

@agahkarakuzu

Copy link
Copy Markdown
Author

Hi @rgaiacs!

One issue is that adding it by default does not apply to repos with dockerfile. Also, people using c.BuildExecutor.appendix would replace those defaults instead of appending to them.

On the other hand, I checked repo2docker picked_buildpack.labels, and they are always present (dockerfile or not), so for a permanent fix maybe it is a better place?

Bottomline, I think this PR restores documented behaviour, and standard OCI labels are a separate improvement that probably belongs in repo2docker.

If you'd rather have a l BinderHub-side default anyway, I'm glad to add it, but I'd want to solve the problem I mentioned first, e.g. a separate appendix_defaults trait or documenting that custom appendix just overrides them.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants