-
Notifications
You must be signed in to change notification settings - Fork 399
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.
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
chore(docs): add missing troubleshooting step #342
base: main
Are you sure you want to change the base?
chore(docs): add missing troubleshooting step #342
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't be needed. Did you deploy wildebeest using the deploy button in the README? It didn't prompt you?
It didn't, that's the reason I opened this |
@sterlingwes could you please go on https://deploy.workers.cloudflare.com, clear your browser's cache / cookies and try the deploy button again? the fields should show up. |
I did that as per the linked issue, multiple times. Have you tried yourself? Used chrome and tried incognito and cache clearing |
Thanks for checking New day, new brain.. and looks like I missed that the deploy button tags on a bunch of query params which are necessary for those fields to show. Those params are stripped from the "done" page URL and they're also not present in the link in the troubleshooting doc, which is I think why I ended up retrying incognito on that link (https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/wildebeest) I'll update this PR to suggest users go back to the deploy button on the Getting Started doc if you think that would be useful? |
Could you remove the link from the troubleshooting doc and redirect users to the get started guide? So we only have one link and it's the correct one. cc @celso |
In another PR I was asked to squash my commits - have you considered changing the default for the repo to squash on merge? That seems to be the standard nowadays since it encourages PRs to be about one thing (leading to one commit on main, but still allowing for granular commits on the branch and not interrupting the review with force pushes) which is a good practice Also lowers the contribution barrier to entry.. i find myself less enthused about contributing anything substantial to this repo when it's so much back and forth over smol readme changes |
Fixes #341 when trying to follow the reset troubleshooting steps and the deploy UI doesn't prompt for all of the GH Action inputs