Trying to move a large-ish project with externally hosted documentation from Travis to Github Actions (It worked with Travis some time ago).
repo = "github.com/Circo-dev/Circo-docs.git",
branch = "main",
devbranch = "main",
push_preview = true
This first attempt deployed to the source repo instead of the external one, with the following logs (Note that the docs repo has the source repo as prefix in its name):
ENV["GITHUB_REPOSITORY"]="Circo-dev/Circo" occurs in repo="github.com/Circo-dev/Circo-docs.git"
│ - ✔ ENV["GITHUB_EVENT_NAME"]="push" is "push"
│ - ✔ ENV["GITHUB_REF"] matches devbranch="main"
│ - ✔ ENV["GITHUB_ACTOR"] exists and is non-empty
│ - ✔ ENV["GITHUB_TOKEN"] exists and is non-empty
Renaming the docs repo did not help, it just does not deploy then.
Is this case supported with Github Actions?
Hmm. As far as I can tell, it should work (although clearly it didn’t).
To make the
Circo-dev/docs-Circo repo work, you could surround
deploydocs with the following
withenv("GITHUB_REPOSITORY" => "Circo-dev/docs-Circo") do
This should bypass the check that is not allowing it to deploy right now. Perhaps this gives a more illuminating error.
To avoid this happening again, I would suggest removing the Documenter deploy key from the source repository – if you’re not going to deploy docs there, Documenter should not have write access to it.
Thank you very much, the
withenv hack made it magically work with the renamed repo!
I am not exactly sure of the intended behavior and the goal of the occursin check (repo url equivalence ignoring the protocol?), but after a quick look it seems that
deploy_folder returns the configured target repo correctly in every case, so the magic happened later.
I think there was no deploy key there, maybe it authenticated with GITHUB_TOKEN? (or I have deleted and forget it in the meantime - a real possibility )
Ah, yes, looking at the logs it looks like this was indeed the case. In this case, I would suggest removing
GITHUB_TOKEN from the workflow, as deploying to a different repository requires
DOCUMENTER_KEY anyway (as far as I know).
It’s there to make sure that the deployment occurs only if the workflow runs in the correct repository (e.g. you do not want to deploy when it runs on forks).