Currently, the set of actions configure-pages, upload-pages-artifact, deploy-pages can work only in the context of the repository that physically contains the given GitHub Workflow.
Use case
The current behavior is a limitation for us in the enterprise environment. We have several hundreds of repositories with GitHub Pages - previously their owners had to manually configure custom workflows and publication to GH Pages in each of them, which was error-prone and blocked us from automating the GH Pages setup. We created a solution that allows running GH Workflows from a central place in context of different repositories to solve this.
Unfortunately, when we tried to run GH Pages publication from such a central workflow, it turned out that the following actions: configure-pages, upload-pages-artifact, deploy-pages don't work in such setup, and always publish the artifact for the repository that contains the workflow, not the one that we want them to run on. As a workaround, we had to fallback to publishing the site from gh-pages branch, but now we need to change the repository settings to make it work (either by juggling the defaults globally, remembering which repository should use what setup, or by requiring owners to manually reconfigure the repositories).
Proposal
We would like configure-pages, upload-pages-artifact, deploy-pages to work between Git repositories:
- workflow is in the repository A
- workflow performs the checkout of repository B
- workflow builds the site from repository B and uses the actions to publish it in context of that repository.
I suspect that the current behavior is the result of security considerations, but maybe additional permissions/tokens could be introduced to introduce such functionality securely?
Additional materials
actions/configure-pages#185 - similar issue raised a couple of months ago for configure-pages.
Currently, the set of actions
configure-pages,upload-pages-artifact,deploy-pagescan work only in the context of the repository that physically contains the given GitHub Workflow.Use case
The current behavior is a limitation for us in the enterprise environment. We have several hundreds of repositories with GitHub Pages - previously their owners had to manually configure custom workflows and publication to GH Pages in each of them, which was error-prone and blocked us from automating the GH Pages setup. We created a solution that allows running GH Workflows from a central place in context of different repositories to solve this.
Unfortunately, when we tried to run GH Pages publication from such a central workflow, it turned out that the following actions:
configure-pages,upload-pages-artifact,deploy-pagesdon't work in such setup, and always publish the artifact for the repository that contains the workflow, not the one that we want them to run on. As a workaround, we had to fallback to publishing the site fromgh-pagesbranch, but now we need to change the repository settings to make it work (either by juggling the defaults globally, remembering which repository should use what setup, or by requiring owners to manually reconfigure the repositories).Proposal
We would like
configure-pages,upload-pages-artifact,deploy-pagesto work between Git repositories:I suspect that the current behavior is the result of security considerations, but maybe additional permissions/tokens could be introduced to introduce such functionality securely?
Additional materials
actions/configure-pages#185 - similar issue raised a couple of months ago for
configure-pages.