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

Accessing the website on a specific server has link breakage #1941

Closed
espadrine opened this issue Aug 18, 2018 · 2 comments
Closed

Accessing the website on a specific server has link breakage #1941

espadrine opened this issue Aug 18, 2018 · 2 comments
Labels
developer-experience Dev tooling, test framework, and CI frontend The Docusaurus app serving the docs site

Comments

@espadrine
Copy link
Member

Reproduction:

  1. Go to https://51.254.114.150/index.html (and accept the self-signed certificate).
  2. Click on the ‘build’ link.

What happens:

What should happen instead:
@paulmelnikow
Copy link
Member

I've also noticed this issue on the main site over very slow connections. I can't easily reproduce it locally, though I notice there is a lag before that # gets added to the location bar. I think part of the problem is that Next has its own router and is designed for SSR, and then we're running our own router inside of one of their pages. And we're not really using SSR.

We should adopt CRA or Gatsby which is the real fix. Meanwhile the workaround is to insert the hash manually.

Also, We could also server index.html from the server root instead of redirecting to shields.io as we do now. I think that would fix the problem.

@paulmelnikow paulmelnikow mentioned this issue Aug 18, 2018
Closed
@paulmelnikow paulmelnikow added frontend The Docusaurus app serving the docs site developer-experience Dev tooling, test framework, and CI labels Aug 19, 2018
@paulmelnikow
Copy link
Member

Hmm, actually, no. I think this was caused by a mistake I made at deploy time, of running make deploy-s0 and, then later, make deploy-s1, without first running make website.

I suspect when that happened, the servers got a copy of the previous gh-pages build.

This was addressed in #1793 but that hasn't been merged yet.

@paulmelnikow paulmelnikow mentioned this issue Aug 22, 2018
Merged
paulmelnikow added a commit that referenced this issue Oct 30, 2018
@paulmelnikow
Rewrite server deploy script (#1793)
94611fb 
To run this requires renaming `private/secret.json` to `private/secret-production.json` in the working tree used for deployment.

Goals:

- Ensure production secrets are not used in development
- Avoid modifying the current working tree
- Avoid branch switching: make sure the current ref gets deployed
    - If something other than `master` is deployed, leave `HEAD` alone; don't reset to `master`
- Ensure the build runs before server deploy (#1941)

This makes use of Git working trees, which is a relatively new but stable feature in Git. I was initially reluctant to use git worktree, mostly because I don't like adding new tooling that isn't necessary. The other alternative I experimented with was copying or re-cloning to an entirely separate working copy. This was messier and more brittle than using `git worktree`.
@dependabot-preview dependabot-preview bot mentioned this issue Dec 31, 2018
Merged
@snyk-bot snyk-bot mentioned this issue Jun 22, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
developer-experience Dev tooling, test framework, and CI frontend The Docusaurus app serving the docs site
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@espadrine @paulmelnikow