Skip to content

Conversation

jandubois
Copy link
Member

See #4134 (comment) for background.


Regarding #4134 (comment), it is now possible to implement this yourself, if you want to:

cat ~/bin/limactl-url-gh
#!/bin/bash
echo "github:$1"l tmpl url gh:jandubois
WARN[0003] The github: scheme is still EXPERIMENTAL
https://raw.githubusercontent.com/jandubois/jandubois/main/templates/demo.yaml

@jandubois jandubois added this to the v2.0.0 milestone Oct 7, 2025
@jandubois jandubois force-pushed the github-redirect branch 2 times, most recently from 922958f to dca4917 Compare October 7, 2025 06:32
@AkihiroSuda
Copy link
Member

On second though the "CORS" restriction may not make much sense for GitHub URLs, as a COMMIT hash in https://raw.githubusercontent.com/ORG/REPO/COMMIT/PATH can (surprisingly) refer to a fork repo outside the ORG

@jandubois
Copy link
Member Author

jandubois commented Oct 7, 2025

On second though the "CORS" restriction may not make much sense for GitHub URLs, as a COMMIT hash in https://raw.githubusercontent.com/ORG/REPO/COMMIT/PATH can (surprisingly) refer to a fork repo outside the ORG

It is not so surprising once you realize that all forks are part of the same repo on the server side, and serve simply as namespaces for branch and tag names.

This is also the reason GitHub does not allow public forks of private repos. Because if the SHA1 of a private commit is leaked, it becomes accessible through the public fork.

I already mentioned before that we don't restrict redirects on http:// and https:// URLs either, so it is a little odd to have them on github: URLs.

But I think the use case is really to redirect from the github:ORG// repo to a different place in the same ORG, not to be a generic link redirector.

I can remove the restriction, if you want; I don't think it matters much either way.

But we can also remove the restriction later, once an actual use case for cross-org linking has appeared.

@jandubois
Copy link
Member Author

While working on the tests for this PR I tripped myself a few times over the problem that except for the root redirect of github:jandubois, all others need to specify a trailing slash to mark them as directories:

l tmpl url github:jandubois//redirect
https://raw.githubusercontent.com/jandubois/jandubois/main/redirect.yamll tmpl url github:jandubois//redirect/
https://raw.githubusercontent.com/jandubois/lima/master/templates/default.yaml

Without the trailing slash redirect is treated as redirect.yaml and cannot redirect to another repo, even if redirect.yaml doesn't exist.

If I can accidentally forget to add the slash while working on the tests, then it is very likely that casual users will also run into it1.

I think we can do 2 things to mitigate it:

  1. Treat foo as foo/ if foo.yaml does not exist (and foo has no extension).

    So we need to make at least a HEAD request for foo.yaml, and if that fails we decide that this was meant to look up foo/.lima.yaml instead.

  2. Allow all *.yaml references (only in ORG repos?) to be symlinks or redirects

    This has the advantage that the user doesn't have to create extra subdirectories as containers for .lima.yaml, as there is likely nothing else in there. Instead foo.yaml could contain the redirect URL (or symlink).

I think (2) is more useful than (1), but if we do (2) and already fetch the file, then we can just do (1) at the same time at no extra cost.

It is just a fallback when foo.yaml doesn't exist, so the alternatives are either return an error right away, or retry the foo/.lima.yaml symlink as well.

I think we should implement both (1) and (2). For consistency we should probably also implement them for non-ORG repos, but of course they would only allow symlinks and not redirects to other repos.

This should again be done in a separate PR because this one is already big enough.

But let me know what you think first!

Footnotes

  1. For similar reasons many websites redirect http://example.com/ to http://example.com (or vice versa).

@jandubois jandubois requested a review from a team October 7, 2025 20:57
@AkihiroSuda
Copy link
Member

❯ l tmpl url github:jandubois//redirect/
https://raw.githubusercontent.com/jandubois/lima/master/templates/default.yaml

I'd rather expect github:jandubois//redirect/ to be expanded as https://raw.githubusercontent.com/jandubois/jandubois/main/redirect/.lima.yaml regardless to the exisstence of /redirect.yaml in the repo.
This should match the behavior of foo/index.html in HTTP servers

@jandubois
Copy link
Member Author

I'd rather expect github:jandubois//redirect/ to be expanded as https://raw.githubusercontent.com/jandubois/jandubois/main/redirect/.lima.yaml regardless to the exisstence of /redirect.yaml in the repo.
This should match the behavior of foo/index.html in HTTP servers

That's what it does. You are seeing the effect of the redirect from there:

curl https://raw.githubusercontent.com/jandubois/jandubois/main/redirect/.lima.yaml
github:jandubois/lima/templates/default

The discussion above is just about URLs without a trailing slash like github:jandubois//redirect, which will always get a .yaml extension and will not be treated as a directory, regardless if the YAML file exists or not.

Currently only .lima.yaml files can be redirects (and directory URLs that expand to .lima.yaml as the default filename).

I think directories without trailing slashes should be able to redirect as well because it is easy to forget to add one, just like people forget to add one to https:// URLs, so the server redirects for you automatically.

Either way, that should be a separate PR from this one.

@AkihiroSuda
Copy link
Member

  1. Treat foo as foo/ if foo.yaml does not exist (and foo has no extension).

SGTM.
Alternatively it may just return an error message that suggests to attempt adding the / suffix

  1. Allow all *.yaml references (only in ORG repos?) to be symlinks or redirects

This restriction sounds confusing

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