Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

bug: minifront version in footer is a broken link #2057

Open
conorsch opened this issue Feb 14, 2025 · 1 comment · May be fixed by #2100
Open

bug: minifront version in footer is a broken link #2057

conorsch opened this issue Feb 14, 2025 · 1 comment · May be fixed by #2100
Labels
bug Something isn't working

Comments

@conorsch
Copy link
Contributor

Describe the bug
When I run the bundled frontend within pd, I see a footer with version and date information:

Image

That's rad. However, the linked git commit is a broken URL.

Expected behavior
I expect that I can click on the abbreviated hash to be taken to a specific commit in the web repo. The specific URL I was shown is http://localhost:8080/app/[email protected]:penumbra-zone/web/commits/ba65187648cbc963c41ea4297e91676720026acd.

Additional context
The problem is two-fold:

  1. the commit sha is interpolated based on the git remote settings, so in my local build i saw [email protected] rather than https://github.com/
  2. the URL is built as a relative path, meaning the pd endpoint is prefixed to it, as http://localhost:8080/app/ in the example above.

Encountered this while working on penumbra-zone/penumbra#5089.
@conorsch conorsch added the bug Something isn't working label Feb 14, 2025
@varunguleriaCodes
Copy link

Hi @conorsch

I'd love to work on this issue! I did some research and found that the "GIT_ORIGIN_URL" variable gets its value from "execSync('git remote get-url origin')". This works fine when the repo is cloned using HTTPS, but if it's cloned via SSH, it returns something like [email protected]:username/reponame. When this SSH URL is used in an tag, the browser treats it as a relative URL, which is why it gets prefixed with "http://localhost:.."

The fix is to detect when the fetched URL is in SSH format and convert it to the corresponding HTTPS link before using it. What do you think? Let me know your thoughts!

@varunguleriaCodes varunguleriaCodes linked a pull request Mar 7, 2025 that will close this issue
Open
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: minifront_version_in_footer_is_a_broken_link varunguleriaCodes/web
2 participants
@conorsch @varunguleriaCodes