Deploy static site without using previous commit

Here’s a scenario I’m able to achieve in Cloudflare Pages, Netlify, or Vercel, but haven’t yet been able to do in Render. Please advise if this is possible now (or would need to be a feature request).

  1. Set up a Render static site off a bare-bones repository (“Repo #1”).
  2. On another repository (“Repo #2”), set up a GitHub Action (GHA) for actual, usual changes to the site. Repo #2 has all the needed credentials in its “Secrets” to access the Render static site.
  3. Disable auto-deploy on the Render static site.
  4. Push a commit to Repo #2, putting the GHA in motion.
  5. This causes the Render static site to rebuild according to what was pushed in this commit to Repo #2, without re-using the last commit from Repo #1.

I have been able to do steps 1–4 so far, but can’t get step 5 to work; every time, Render accepts the “trigger” from the GitHub Action but ignores the data coming from the GHA and, instead, insists on using the most recent commit to Repo #1. For the GHA step involving actual deployment to Render, I have incorporated multiple Render-specific GHAs from the GHAs Marketplace and get this result with each one.

Is there a way to achieve step #5?

Additional note: With CFP, Netlify, and Vercel, I was able to disconnect the static site from the repo to perform steps 1–5. I see no way to do that with Render, so perhaps that’s part (or all) of the problem?


A Render service is linked to a repo directly. If the Render service is linked to Repo_1, then any attempts to deploy, e.g.:

  • a push to Repo_1 on Github (with Auto-deploy enabled),
  • manual deploy,
  • pinging the deploy hook
    Will trigger a deploy, pulling from the linked Repo_1.

I’m curious to know more about the use-case here. If the “usual changes” are made to Repo_2, then why not connect that repo to the service?

I feel like I’m missing something obvious.


One use case is for switching between hosts, such as during tests or prolonged outages. I wouldn’t want to have duplicate content remaining in two different deployments, for fear of causing SEO issues. Hence, the bare-bones deployment from Repo #1 is live on one host, and the GHA deployment from Repo #2 with the real site content is live on the other host. After the precipitating event (test, outage, etc.) is over, the situation could be reversed.

As Render currently does this, as opposed to how it works on those other hosts I mentioned in my Additional note, Repo #1’s content isn’t overridden by the GHA for Repo #2, thus making this impossible.

I described some of the logic behind this here, although this was more about switching between different static site generators (but the method was the same):

As for the question of “Why not just connect Repo #2?” as opposed to using the GHA: there are a few things you can specify with a GHA, by building on GitHub’s platform rather than the final host’s, that you can’t otherwise or without some difficulty — e.g., controlling Git fetch-depth.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.