Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

keep_files=true does not work when force_orphan=true #455

Open
trangdata opened this issue Aug 18, 2020 · 8 comments
Open

keep_files=true does not work when force_orphan=true #455

trangdata opened this issue Aug 18, 2020 · 8 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@trangdata
Copy link

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?

@trangdata trangdata added the bug Something isn't working label Aug 18, 2020
@peaceiris peaceiris added enhancement New feature or request and removed bug Something isn't working labels Aug 18, 2020
@peaceiris peaceiris added this to the v4.0.0 milestone Aug 18, 2020
@peaceiris
Copy link
Owner

peaceiris commented Aug 18, 2020

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).

peaceiris added a commit that referenced this issue Aug 18, 2020
the keep_files does not support working with the force_orphan with the v3.

Related to #455
peaceiris added a commit that referenced this issue Aug 18, 2020
the keep_files does not support working with the force_orphan with the v3.

Related to #455
peaceiris added a commit that referenced this issue Aug 18, 2020
the keep_files does not support working with the force_orphan with the v3.

Related to #455
@trangdata
Copy link
Author

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

@trangdata
Copy link
Author

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
Copy link
Owner

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

@ElliotSilver
Copy link

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
Copy link

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
Copy link

yashash-pugalia commented May 10, 2022

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

@bilelmoussaoui
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants