Deploying docs to another repo with Github Actions

Trying to move a large-ish project with externally hosted documentation from Travis to Github Actions (It worked with Travis some time ago).

deploydocs(
    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

withenv("GITHUB_REPOSITORY" => "Circo-dev/docs-Circo") do
    deploydocs(...)
end

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.

2 Likes

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 :slight_smile: )

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).

2 Likes

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).

1 Like