proposal: option to not follow symlinks when copying assets

[davidhewitt]

Checklist

• I am using the latest version of this aciton.
• I have read the latest README and followed the instructions.
• I have read the latest GitHub Actions official documentation and learned the basic spec and concepts.

Describe your proposal

At the moment the copyAssets step follows all symlinks to fetch their content:

actions-gh-pages/src/git-utils.ts

Line 60 in 2decf4e

cp('-RfL', [`${publishDir}/*`, `${publishDir}/.*`], destDir);

(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 to true to keep existing behavior.

If set to false, copyAssets uses -P switch instead of -L.

I want to use followSymlinks: false plus keepFiles: 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:

  [INFO] first deployment, create new branch gh-pages
  [INFO] no such file or directory: /home/runner/work/pyo3/pyo3/public/latest
  [INFO] chdir /home/runner/actions_github_pages_1628498412192
  /usr/bin/git init
  Reinitialized existing Git repository in /home/runner/actions_github_pages_1628498412192/.git/
  /usr/bin/git checkout --orphan gh-pages
  fatal: A branch named 'gh-pages' already exists.

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 new gh-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.

[peaceiris]

About the failure

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.

About the suggestion

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.

[davidhewitt]

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.

[davidhewitt]

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 🙂

[vulder]

This feature sounds great 🎉
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 😍.

[kousu]

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: neuropoly/neuro.polymtl.ca@f371d46#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051

So, also very much looking forward to this!

And thanks for making such a tidy and well-supported Action :)

[oeyoews]

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.