You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This generates rustdoc and then uploads the generated files to GitHub Pages.
I'm hoping to extend our GitHub pages to also upload a copy of the generated rustdoc for each in-flight PR so that we can preview what the docs will look like. I believe this should be possible with only a small addition to this Action: namely, the ability to specify a target subdirectory when deploying an artifact. This should in theory only require one extra input to the Action:
steps:
- name: Deploy to GitHub Pagesid: deploymentuses: actions/deploy-pages@v4target: a/b/c
The target input would be optional, and default to .. It would instruct the Action to overwrite not necessarily the entire deployment, but a specific subdirectory of the deployment. This would allow us to write something like:
I have a similar use case just with YARD documentation and I would also like to upload an HTML Tests and Coverage report.
Right now I'm just re-running the tests in my "Generate Documentation" action but I'd rather upload these things from my normal "RSpec Tests" action (on merge).
TLDR: Can this Action support this workflow natively?
My project currently uses this configuration to publish to GitHub Pages from the
main
branch:This generates rustdoc and then uploads the generated files to GitHub Pages.
I'm hoping to extend our GitHub pages to also upload a copy of the generated rustdoc for each in-flight PR so that we can preview what the docs will look like. I believe this should be possible with only a small addition to this Action: namely, the ability to specify a target subdirectory when deploying an artifact. This should in theory only require one extra input to the Action:
The
target
input would be optional, and default to.
. It would instruct the Action to overwrite not necessarily the entire deployment, but a specific subdirectory of the deployment. This would allow us to write something like:...and invoke this from a workflow triggered by each PR.
The text was updated successfully, but these errors were encountered: