keep_files=true does not work when force_orphan=true

[trangdata]

I'm using v3, and when I added the force_orphan: true option in my deploy step, keep_files: true seemed to stop working. Existing files on gh-pages were not kept.

The corresponding commit is EpistasisLab/pmlb@67f34be, whose actions log is here.

What I was hoping was to keep the existing files, add changes, then deploy to gh-pages as a single commit. If this is not possible, perhaps a warning would be helpful for users who expected the two options to work together?

[peaceiris]

Thank you for the feedback.

I'm using v3, and when I added the force_orphan: true option in my deploy step, keep_files: true seemed to stop working. Existing files on gh-pages were not kept.

This is a spec. Yes, we need a warning message or termination with a message that tells users that keep_files does not work with the force_orphan option. I did not consider this use case since I am a user of Static Site Generators. (It generates new deployment assets every build.)

Maybe, the keep_files will support working with the force_orphan option in the next major release (version 4).

[trangdata]

Amazing! I look forward to the support! Thank you!

[trangdata]

I should elaborate on why this functionality would be helpful for our use case: We have almost 150+ large HTML files that we sometimes have to regenerate and pushed to gh-pages. force_orphan: true would help us reduce the size of the repo significantly without having to manually squash the gh-pages commits.

Thanks again, and I look forward to the next release!

[peaceiris]

Yes, it looks a practical use case. We need v4.

[ElliotSilver]

We have similar need. Our output is generated by running the master branch through a build process. We want to publish current content, as well as milestone ("v1.0") content. Regular commits should trigger publication to /current, tagging should trigger publication to /{tag}. For the "current" directory, the content of that directory on the gh_pages branch should be replaced each time with the latest build. However, we don't want to touch out anything on that branch in a milestone directory, or in the root directory.

• /
  • current <- only directory updated on a regular commit
  • v1.0 <- directory created when master branch is tagged "v1.0" and not modified after
  • v1.1 <- directory created when master branch is tagged "v1.1" and not modified after

This may be related to #273, although each build only contains the content for the in-process build, not the other milestone content.

[briantist]

I would like to add another vote for this. I have a similar use case to @ElliotSilver .

I do use a generator for static files, building documentation for Ansible collections. But I have a workflow where we will use subdirectories, like:

• /branch/<branch name>
• /tag/<tag name>
• /pr/<pr#>

So that we can publish docs for each PR, on every push, showing the changes, and we can also have more stable docs for tags and branches (especially main).

This is working great already with keep_files: false and destination_dir, but for a repository with about 4MB of total files, and few test publishes has resulted in around 30 MB of rendered docs, which has doubled the compressed size of the repository already. So I am worried about real-world usage and accumulation of commits.

As reported however, this strategy will not work with force_orphan/keep_history, because even though keep_files works correctly with destination_dir, the force_orphan option is not preserving existing files.

If there is a solution for this, I would be very grateful!
Thank you for all your work on this action.
ありがとうございます

[yashash-pugalia]

yes please can't wait for v4 for this to work

[bilelmoussaoui]

What I was hoping was to keep the existing files, add changes, then deploy to gh-pages as a single commit. If this is not possible, perhaps a warning would be helpful for users who expected the two options to work together?

Indeed, I ended up losing a bunch of rather manual changes I had in gh-pages...