Option to tag the commit as well

[xxxserxxx]

Describe the solution you'd like
An optional tag: key with which to tag the commit.

Additional context
This would be useful when the action is being used on an ancillary repository to synchronize workflows.

In my case, I have a project that, when published, triggers a number of other project workflows to start; these helper workflows do things like update Homebrew recipes and build Arch AUR packages. I'm using git-auto-commit-action to commit the changes being made by the workflows; it'd be great if the repos could also be tagged with the same tag as the upstream project tag that kicked everything off; for this, I'd need git-auto-commit-action to also tag the commit.

[stefanzweifel]

Yeah, I thought about adding a tag-option to over the last few days too.

In the meantime, I think something like this should already work:

- uses: stefanzweifel/[email protected]
  with:
    commit_message: Apply automatic changes

    # Optional git params
    commit_options: '&& git tag -a v1.0.0 -m "v1.0.0"'

The commit_options is just appended to the git commit-call. (Source)

[xxxserxxx]

I'll give that a try, thanks.

[stefanzweifel]

Hello again,

I've just released v4.1.0. You can now provide an optional tagging_message, which will create a git tag for you and push it to the remote branch.

• Release: https://github.com/stefanzweifel/git-auto-commit-action/releases/tag/v4.1.0
• Implementation PR: Feature: Tag commit created by the Action #50

Hope this works for you.

[xxxserxxx]

Thanks! I'll let you know next release when I tag something about just how awesome it is.

[xxxserxxx]

@stefanzweifel this works a treat. I do have question, though, and it's probably related to my not understanding something about either workflows or this action.

My changes and tags are showing up on a branch, not on master. Looking at the repo, the changes are not on master, but I can see the tag in the drop-down, and if I switch there, I see the changes. If I pull the tag in a clone, git merges the tag onto master and if I then push it, the changes show up.

Am I missing an option? Did adding the tag function change how git-auto-commit is working? Was git-auto-commit always committing changes to a branch?

Thanks

[stefanzweifel]

Happy to clarify questions. Sorry, for the wall of text.

My changes and tags are showing up on a branch, not on master.

Depending on how you've configured your Workflow, the tag is indeed only showing up on the branch. Or said in another way: The Action pushes the created tag to the same branch, to which the commits is pushed to.

Here's the demo project + workflow I usually use to test this Action. (It's a PHP app, but you get the gist.)

https://github.com/stefanzweifel/git-auto-commit-action-demo-app/blob/e86574ba1d63517b59a46949f8f76a5ec2fc0f0b/.github/workflows/format_php.yml

Here I'm listening to the pull_request-event. Meaning the Workflow only runs, when a PR is opened. All the changes are always pushed to the branch for the pull request. Never to master.
This is due to my input option branch: ${{ github.head_ref }}.

---

Looking at the repo, the changes are not on master, but I can see the tag in the drop-down, and if I switch there, I see the changes.

This sounds like a feature of GitHub. They list every tag in a repository, no matter the branch the tag has been pushed on. ↓

If I pull the tag in a clone, git merges the tag onto master and if I then push it, the changes show up.

Without knowing your exact setup this is quite a hard question to debug. 😅

I assume your workflow listens to the pull_request event. (Meaning if you open a new pull request and push commits to it, the workflow is run.)
Maybe the workflow looks similar to this:

name: php-cs-fixer

on: pull_request

jobs:
  php-cs-fixer:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.head_ref }}

    - name: Run php-cs-fixer
      uses: docker://oskarstark/php-cs-fixer-ga

    - uses: stefanzweifel/[email protected]
      with:
        commit_message: Apply php-cs-fixer changes
        branch: ${{ github.head_ref }}
        tagging_message: 'v1.x.x'

Whenever a change is detected in the pull request branch, a new commit would be created and the commit would be tagged with whatever string is passed to the tagging_message option.

Only now I've discovered, that this is probably not the smartest idea. I think this could lead to duplicate git tags (I think).

It would probably be better to listen to another GitHub event. However, their documentation does not list any event which would make sense to me, for when to create a tag: https://help.github.com/en/actions/reference/events-that-trigger-workflows

---

Am I missing an option? Did adding the tag function change how git-auto-commit is working?
Was git-auto-commit always committing changes to a branch?

Yes, the Action always just did that: Make a commit of the change and push the changes up to the remote repository.

The tagging feature was only just a small addition. It doesn't have any impact on the other functionality.

[xxxserxxx]

I thought about uploading the workflow. I'll attach it:

update.yml.txt

name: Update tap

on: 
  repository_dispatch:
    types: [my-release]


jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@master

      - name: Update recipe
        shell: bash
        run: ./update.sh "${{ github.event.client_payload.tag }}"

      - uses: stefanzweifel/[email protected]
        with:
            commit_message: Update recipe to version "${{ github.event.client_payload.tag }}"
            tagging_message: ${{ github.event.client_payload.tag }}

            # Optional glob pattern of files which should be added to the commit
            file_pattern: gotop.rb

            # Optional commit user and author settings
            commit_user_name: Tap Updater
            commit_user_email: [email protected]
            commit_author: Tap Updater <[email protected]>

I'd read about the branch option; I am not using it, which is what confuses me.

[stefanzweifel]

Thanks for the workflow file. (I've edited your comment to include the workflow directly in the comment, so it's a bit easier to read.)

Your workflow is setup to listen to the repository_dispatch-event. I haven't used of that before. Apparently, this is dispatched through an outside event. (Docs).

I guess actions/checkout is checking out the exact SHA of the commit. In previous versions of the actions/checkout-Action, there was a problem that a repository was often checked out in a detached state and with the exact SHA.
This Action (git-auto-commit) would then have trouble pushing to the right branch.

I guess, this is happening here too.

---

My assumption about what you want to achieve here:

1. Make API call to GitHub to trigger workflow
2. Checkout the master-branch of the repository
3. Run your update.sh script
4. Create a new commit, tag the commit and push the changes back to master

I think you could accomplish this by being explicit, which branches should be checked out. Your workflow might then look like this.

name: Update tap

on: 
  repository_dispatch:
    types: [my-release]


jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@master
+       with:
+           ref: 'master'

      - name: Update recipe
        shell: bash
        run: ./update.sh "${{ github.event.client_payload.tag }}"

      - uses: stefanzweifel/[email protected]
        with:
+           branch: 'master'
            commit_message: Update recipe to version "${{ github.event.client_payload.tag }}"
            tagging_message: ${{ github.event.client_payload.tag }}

            # Optional glob pattern of files which should be added to the commit
            file_pattern: gotop.rb

            # Optional commit user and author settings
            commit_user_name: Tap Updater
            commit_user_email: [email protected]
            commit_author: Tap Updater <[email protected]>

---

I'd read about the branch option; I am not using it, which is what confuses me.

The branch-option is just a way to override the behaviour of git and explicitly tell git, where the commit should be pushed to.

The Action is in it's core also just a very basic bash script. Here are the lines of code which are responsible of creating the commit and pushing it to a remote repository.

[xxxserxxx]

Interesting.

So, yes. In my use cases, I have:

• A master project repository (gotop)
• A number of release repositories for different distribution channels (homebrew-gotop, archlinux-gotop, etc)
• When I publish a release on gotop, a workflow runs that sends dispatch events to the distribution repositories which, in turn, trigger these workflows.
• The distribution repositories do whatever magic is necessary for each channel (updating versions and SHAs), push them downstream or whatever is needed to "release" for that channel, and then tag and commit the changes.

Separating into different repos prevents too much churn and bulk in the main project. The tagging is so that I can link releases across repositories. I would actually think that tagging a branch would be a great thing, except some channels (like NixOS) expect tags to be on the master branch and get discombobulated if you step outside of that. And I don't have control over those channels.

I'll give your suggestion a try -- I'm sure it'll work just fine, thank you.

[stefanzweifel]

Sounds like a great idea to automate the entire release process. 👍

I personally always create a tag on master. So I guess hardcoding the branch to master should fix your problem.