@mterhar made a good suggestion

We could have it check if it's a fork and if so, deploy to github pages for that repo
if: github.repository == 'cdr/code-server' then run our preview app.
if: github.repository != 'cdr/code-server' then run a github pages deploy

@jawnsy said to look here: https://docs.github.com/en/actions/reference/environments

#4020 (comment)

Another option would be to skip this workflow if it's from a fork, but then we might not catch bugs 🤔

@bpmct found a good solution to this:

However, it looks like we can allow forks to use the secrets from the upstream repo and even add approvals. https://dev.to/petrsvihlik/using-environment-protection-rules-to-secure-secrets-when-building-external-forks-with-pullrequesttarget-hci

While this comment doesn't help code-server repository in isolation, I'd like to throw-in that maybe we should longer-term seek a way to preview docs changes that don't require cloning a monorepo - there's probably a minimal environment we can move to a public repo like cdr/docs-engine or something along those lines

Yeah, and the other advantage of a public project repo is that we can next export those docs and include them in the product itself, which helps for air-gapped installs

Hmm... I know this is not my place, but can't we get the Vercel app(noticed the Coder site is deployed on Vercel)? I mean, after installing Vercel over here, and enabling that, if anyone makes a PR, even if or if it's not a docs change, it will give a preview, just to be on the safe side. You don't need extra files, all you would need is the Vercel app. Since the repo is directly connected there, it's easier than tokens and workflows, right?

Edit: By "safe side", I meant, no breaking changes on the docs.

@im-coder-lg Great question, and thanks for your contributions! We definitely want to make it easier for people outside our company to contribute to code-server, hence this issue.

The reason that the preview workflow doesn't work for external contributors is that it requires a cross-repository access token, as it clones a private repository, which includes our documentation site, and uploads it to Vercel using our credentials. We've been thinking about ways to remove this limitation, perhaps by extracting the docs site into an open source project, or by making the credentials accessible to external contributors through a feature like GitHub Actions Environments, but we haven't resolved that yet.

Your suggestion to investigate having Vercel build our site instead (using a webhook or similar to trigger it) is a good one and one we'll investigate as well. Thanks for that!

Still an issue unfortunately. It appears the environment and secrets are set up, but they're not being recognized when CI runs on forks. @jawnsy suggested "checking the length of "${{ secrets.READONLY_M_DEPLOY_KEY }}" to make sure it's set to something"

We can also enable debug logging.

Resources

• https://github.com/coder/code-server/blob/main/.github/workflows/docs-preview.yaml#L29-L36
• https://github.com/actions/checkout#usage
• https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#environment-secrets
• https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging

perhaps by extracting the docs site into an open source project

I think that might work. It might also bring in more contributors who want to help make JS components since the website's Next.js-based(I got that from the devtools from my browser). Moreover, it might even help to triage Next.js issues.

I don't think we'll go that route sadly (I think since it's bundled with the main site, it would be too difficult of a task). But hopefully we can find an easy alternative!

I just kinda hit an idea - Netlify. The reason I suggest it is because it has 100 GB of bandwidth, teams, reviewers(website), etc. It has Deploy previews that have a collaboration feature. Although it uses BrowserStack to judge your OS if you review through the previews. The best thing with Netlify is a CMS panel(you'll have to do some coding around to enable it here) so it's easy to edit too. Any ideas?
PS: The reviewers feature is cool but authorized Netlify users only can review - to do that, they'll have to post a comment via the website, it asks the owner of the website to approve the user and if approved, you can log in again and post comments through that. The webpage path, your OS and browser data is also given via BrowserStack(kinda irritating though).
Only problem is that you'll have to tell who posted the comment. It tells that only on the website.

That could work! We use Vercel already though so I don't know if it would be complicated using both Vercel and Netlify. Definitely worth considering though! I'm going to get to this shortly and then I'll share what approach we'll take.

I actually am one of the people who deploy on both CDNs for the same project, and I think it's worth it, since Vercel is one of the best CDNs available and Netlify's Deploy Previews make it easy to review the site, so it's easy to request changes. I think you can make the deploy workflow only ofor theain branch and enable Netlify safely. That might work nicely.

Oh really? I didn't know we had an expert in the house! Okay well I'll keep that in mind and I'll ping you when we work on this.

I'd kinda hate to boast, but I am kind of professional in Vercel and Netlify deployments. I think I got an idea. You use Netlify for Deploy previewing, whereas you reprogram the Vercel workflow to deploy only on pushes to the main branch. I think this might solve the problems. Also, don't forget to add a good Netlify config. It's toml, so you will have to click the square brackets key often. Here's how I use it on two of my projects:

• If it's a folder inside a repo: https://github.com/TimerX-App/TimerX/blob/master/netlify.toml
• If it's a repo itself: https://github.com/im-coder-lg/docusaurus-blog/blob/main/netlify.toml

Both are from projects I contribute/own, so it's secure! But remember, mine is Docusaurus, based on React.js so you will have to tune the config as needed :)

If you need some more help, try contacting me on Slack. I'll respond as soon as I can!

You use Netlify for Deploy previewing, whereas you reprogram the Vercel workflow to deploy only on pushes to the main branch. I think this might solve the problems.

That might work actually 🤔 I want to at least try getting Vercel deployments to work. If that doesn't work, we could consider this option. Thank you for suggesting!!

I'm going to start working on this right now.

Notes

I'll update this comment with my notes as I go.

Does this problem still exist?

To check, I need to open a PR from a fork.

Root cause

It appears to be a known limitation of GitHub Actions secrets. They can't be made available to forks.

Solutions?

Build site with a tool like eleventy: npx @11ty/eleventy --input=docs --output=_site --formats=md --serve --port=3000 and then deploy to GitHub Pages or Netlify. Looks very raw and ugly though.

Guess we'll just have to skip this on forks if not available

This might help: https://stackoverflow.com/a/68804665/3015595

And this: https://github.community/t/how-to-detect-a-pull-request-from-a-fork/18363

Seems to me like you are getting an idea on this... Then how would you preview the docs?

@im-coder-lg sadly, I don't think you'll be able to :( We'll have to thoroughly check the docs in PRs but we won't have a live preview.