Option to not have empty commits

[kingofzeal]

Love the work on this. One question for an enhancement:

I'm curious if a option can be added to either opt in (or opt out, either way) of creating empty commits when publishing.

Basically, I would rather my publish branch (gh_pages) only reflect changes to my site when things actually change. This is especially noticeable as I'm building up my workflow, which is understandably an incremental process.

It looks like the fix would be pretty straightforward here (removing the --allow-empty flag), but I also understand that some may want this behavior, and I'm unsure how to make it something optional.

I can look into it when I have some time, but I probably won't get to it very quickly, so wanted to throw it out to see if someone might be able to pick it up before I can.

[peaceiris]

Thank you @kingofzeal

We can use on.push.paths but this is a temporary expedient.

e.g. Hugo project

on:
  push:
    branches:
    - master
    paths:
    - '.github/workflows/*'
    - 'config/*'
    - 'content/*'
    - 'static/*'
    - 'themes/*'

When I update /README.md and push the commit to a remote master branch, I can skip a workflow with this setting.

[peaceiris]

Thank you. I checked #22. I think that this behavior is not kind to users. If we want to change the option, we have to update the workflow file. It looks the same as commenting out of this action.

How about [skip cd] feature like [skip ci]? I have my idea to implement it. When committer creates commits that include [skip cd] in commit messages, this action skip deploying.

[kingofzeal]

I think I understand what you're thinking. I can see that being useful, but it still doesn't necessarily work for my use case, for the same reasons a paths configuration doesn't - because it does force me to know in advance if a given commit would normally result in a published change.

Let me give a couple other examples/use cases I was thinking about in addition to what I had in the initial comment. These still revolve around the idea that I don't want to muddy the publication branch with commits that make no changes.

Site refactoring

I'm currently in the process of converting a website from a pure static website (only HTML files, no templating, etc) into Hugo. Hugo makes this incredibly easy to do while generating the same HTML output as I started with. However, I want to take advantage of some of the features the engine offers such as templating, better separation of content vs style/layout, alternative themes, etc. It's very much a work-in-progress. Theoretically, every change I do should result in the exact same output, but... maybe not. I won't say there aren't options for me to check if the output will change or not on a given commit, but having to determine that up front can be tedious, especially since I'm trying to focus on taking as much advantage of the engine as I can.

Future dating

Back when I was more actively blogging, I had a habit of wanting to spread out my posts over time, even if they were ready to go right away. To accomplish this, once I was done with a post I would set something like a publishDate parameter in the front matter to some time in the future, and had the engine configured to not generate any HTML for content that was set in the future. However, I would obviously want to have it published on that day, so I set up the build system to run every day via cron. When the day finally came, the HTML for the new post would be generated and published without making any changes to the code.

I can understand the desire to not want to muddy things with a bunch of configuration settings for every little thing (and I'll be the first to admit this is a pretty minor thing), but I'm not sure of any better way of accomplishing these types of use cases except by dropping the allow-empty flag when committing to the publication branch. This allows the question of "was something changed" to be offloaded to Git, which will be able to better answer it than I will ever be.

Your thoughts on it and my thoughts aren't really mutually exclusive either. I can see benefit in being able to manually override/suppress the publish from a commit, but I personally don't have much value or use case in such an option.

[peaceiris]

Thank you for your additional use cases and details. I got it clearly. We need this feature. Let's enhance your Pull Request #22.

[github-actions]

This issue has been LOCKED because of it being resolved!

The issue has been fixed and is therefore considered resolved.
If you still encounter this or it has changed, open a new issue instead of responding to solved ones.

Log | Bot Usage