git-auto-commit-action
git-auto-commit-action copied to clipboard
Make commit and push into separated optional steps
Is your feature request related to a problem? Please describe. I have a repository with two workflows:
- A scheduled workflow 1 that downloads update data from different sources and create one commit for each source.
- A on-push workflow 2 that triggers on new data, analyzes the data and create a new commit.
As soon as workflow 1 commits data from first source, it triggers workflow 2. As the two workflows now run in parallel and both may have new commits, further commit from one workflow will be rejected.
Describe the solution you'd like Add an option to disable the commit or push step of this action. As in workflow, the push event may be intentionally used to trigger other workflows, it makes sense to provide more controllable push to me. In my case, I want workflow 1 to create multiple commits without push, and a single push at the end of the workflow.
Thanks for the suggestion! This is something we could add to the Action and is something I will consider adding.
The only issue I currently see is in educating users how this feature should be used. For example, users might want to write a single workflow with 3 job steps:
- Job 1 generates changes and creates a commit
- Job 2 generates changes and creates a commit
- Job 3 generates changes, creates a commit and pushes 3 commits to GitHub
This won't work, as the state of each job is independent. Job 1 doesn't know about the state of the git repo in Job 2. The commit would have to be pushed in each job, as it would otherwise get lost forever.
But users who would build such workflows/jobs probably already know, that they have to checkout their repo in each job step.
Oh, I just noticed that maybe I can achieve this by simply passing push_options: --dry-run
to the action
push_options: --dry-run
sounds like it should do the tricks, at least when running under one job and under one git repo clone. The question is, will the last action invocation that's meant to push indeed attempt to git push
even if it didn't create any commits itself (when only the previous ones happened to create any)?
It seems like it does not. The action in case there was nothing to commit shows this output:
Working tree clean. Nothing to commit.
But if git push
was invoked, it'd show this, which was not shown:
Everything up-to-date
So properly supporting this might require two new options, one to skip pushing, and one to always attempt pushing... (or just always attempt pushing even if no commit creation was expected?)
You're right. In my own repo I didn't rely on this action for the final push and simply call a run: git push
at the end, so I didn't notice this.
@stefanzweifel btw does push have to be protected by the status check? Pushing with no change seems to be harmless.
If we put this step outside the if
block, this action can be used to push changes committed before running the action.
@ZeroRin
btw does push have to be protected by the status check? Pushing with no change seems to be harmless.
When I developed the Action, this made the most sense (and it still does to me). Only push something, if something has been committed and – therefore – the repo has been dirty.
Do you have in mind, that the Action the would always execute _push_to_github
?
So the Action would output "Working tree clean. Nothing to commit." and then try to push to GitHub.
If we do that, I think we would have to test different scenarios. On top of my head the following come to mind:
- what happens if remote is out of sync and we try to push?
- what happens if repo is not dirty but a tag should be created and pushed?
Maybe it would make sense to split the logic of the Action in to 2 buckets: "Creating Commit" / "Pushing Commit". Both features can individually be enabled/disabled. By default both are active.
[…] this action can be used to push changes committed before running the action.
I think something got lost in translation here. Would you use the Action like this?
# This step would always try to push something.
- uses: stefanzweifel/git-auto-commit-action@v4
- name: Change Files
run: # Do something to make repo dirty
# This step would create a commit and push it.
- uses: stefanzweifel/git-auto-commit-action@v4
Would be so great if you could share workflow examples of how you intend to use the Action.
@stefanzweifel This is my actual workflow To simplify, it's a scheduled workflow that works like:
- name: Change Files
run: # Do something to make repo dirty
# This step would create a commit for data source 1 if there is change
- uses: stefanzweifel/git-auto-commit-action@v4
with:
commit_message: source 1 autoupdate
file_pattern: data/source1
push_options: --dry-run
# Same for date source 2
- uses: stefanzweifel/git-auto-commit-action@v4
with:
commit_message: source 2 autoupdate
file_pattern: data/source2
push_options: --dry-run
# Same for date source 3
- uses: stefanzweifel/git-auto-commit-action@v4
with:
commit_message: source 3 autoupdate
file_pattern: data/source3
push_options: --dry-run
# A final step that push all the changes
# To cope with other workflows that triggered on push
# this action is not allowed to push anything until all commits are done
# Now I'm using a command run here but I would like to use action here
- run: git push
In the final step we are facing a state where there is only committed but un-pushed changes, which would not be picked up by the action.
@ZeroRin Thanks for sharing the workflow. This makes understanding your problem much easier and I can see that this is a legitimate usage of the Action.
My plan is to work on the Action more in December/January. Will try different things and hopefully release a new version with this feature soonish.
I'm closing this issue and will not implement this "split commit and push" feature, although I mentioned that I understand that it could be useful.
I currently don't see a good way on how to implement this into the action. Adding more config-values makes the code more complicated and brings a maintenance burden on to me, which I don't want to take on.
In cases where such a feature might apply, it's probably easier to write the git-add
, git-commit
and git-push
statements yourself.
Thanks for suggesting this feature and giving feedback on this action.