Open davidhewitt opened 3 years ago
I am using the latest version of this action.
I am very happy to check and follow this before opening an issue.
Could you use the latest version (v3.8.0)? You are using the beta release v3.7.0-8. It gives the failure.
I would actually like to deploy a symlink to my gh-pages environment rather than copy the contents.
Currently, the copyAssets
follows all symbolic links to resolve the case in which a publishing directory has a symbolic link to a file on a parent directory. I also think that the copyAssets
do not need to follow symbolic links pointing to files in a publishing directory. I have a plan to rewrite copyAssets
in the future release (perhaps in the next major). To track the plan, watch the v4.0.0 Milestone.
Could you use the latest version (v3.8.0)? You are using the beta release v3.7.0-8. It gives the failure.
My mistake, I will update my CI process. I gained the impression from reading the actions-gh-pages
source that this issue still exists on 3.8.0.
A follow-up on this: it looks like updating to a newer gh-actions-pages
fixed the crash. The symlink still failed to update though. I guess for that I'll need to wait for v4 š
This feature sounds great :tada: Deploying symlinks instead of copying the complete folder would help us a lot to simplify our setup and would also save a bit CI time. Looking forward to it :heart_eyes:.
Also looking forward to this!
I was using https://github.com/crazy-max/ghaction-github-pages/tree/v2 and didn't think much about how it handled symlinks.
I just tried upgrading to this action instead because it handles .nojekyll
and CNAME
inline, and pushes commits on top instead of wiping and repushing the entire gh-pages
branch every time, and tags the deployed commit ID in the gh-pages
commit it makes, and generally seems better supported, but I did immediately notice that it copied instead of symlinked this file: https://github.com/neuropoly/neuropoly-docs/commit/f371d46e964105a54ac43a92355e499236168b8c#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051
So, also very much looking forward to this!
And thanks for making such a tidy and well-supported Action :)
I'm trying to switch from ubuntu-latest to macos-14, and I encountered the problem in the picture. I'm not sure if it's the same reason.
Checklist
Describe your proposal
At the moment the
copyAssets
step follows all symlinks to fetch their content:https://github.com/peaceiris/actions-gh-pages/blob/2decf4e752abab9095efc5ace22a0e92ae2e6fec/src/git-utils.ts#L60
(The
-L
switch enables this behaviour.)I would actually like to deploy a symlink to my
gh-pages
environment rather than copy the contents.Describe the solution you'd like
Could we add a
followSymlinks
option, which defaults totrue
to keep existing behavior.If set to
false
,copyAssets
uses-P
switch instead of-L
.I want to use
followSymlinks: false
pluskeepFiles: true
to create a CI job which updates a symlink and does nothing else.Describe alternatives you've considered
-
Additional context
In fact, I am actually attempting to create the symlink in a CI job, and it's creating an interesting failure:
https://github.com/PyO3/pyo3/runs/3278446262?check_suite_focus=true
The relevant log is:
Looks like the
copyAssets
step fails because this symlink is dangling in the local checkout. This then causes the action to try to initialize a newgh-pages
branch, which is incorrect and causes a crash.So there's maybe also a separate bug here about failure in the
copyAssets
step causing the action to incorrectly switch to first-deployment mode.