disable workflow on protected branch

[gogo2464]

accordoing to the doc: https://github.com/stefanzweifel/git-auto-commit-action#commits-made-by-this-action-do-not-trigger-new-workflow-runs I have to set the PAT to push on protected branch.

Sadly it triggers workflow unexpectdly : https://github.com/stefanzweifel/git-auto-commit-action#commits-made-by-this-action-do-not-trigger-new-workflow-runs

What can I do to disable workflow on protected branch please?

Here is my workflow: https://github.com/gogo2464/cryptatools-rs/blob/master/.github/workflows/deploy-pypi-on-windows.yml#L44

[stefanzweifel]

If you're using a PAT you're responsible for guarding your workflows from unexpected runs.
For example, you can add a if-clause on the job level like this.

name: Deploy

on:
    push:

jobs:
    deploy:
        name: Deploy
        runs-on: ubuntu-latest
        # Run this job if the commit message is not equal to "Change version with bump2version"
        if: github.event.head_commit.message != 'Change version with bump2version'
        steps:
            - run: # Deploy code

See:

• workflow triggers itself on push #237 (comment)
• https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idif
• https://docs.github.com/en/actions/learn-github-actions/contexts#github-context

[gogo2464]

@stefanzweifel I tested. It actually stops the workflow but seems ugly. Is there a better way please?

[gogo2464]

@stefanzweifel also this can not work because I do an --amend https://github.com/gogo2464/cryptatools-rs/blob/master/.github/workflows/deploy-pypi-on-windows.yml#L51

[stefanzweifel]

[…] but seems ugly. Is there a better way please?

As far as I know, there is no other way. And I think it's rather expressive. When reading you're workflow you immediately know why a certain portion of your workflow is not executed. :)

also this can not work because I do an --amend

I don't have the time to test it, but why shouldn't/doesn't this work? Isn't your push registered by GitHub; even if it's an ammend?

If this doesn't work, then I don't have another solution.

git-auto-commit is a very simple Action that executes a couple of git-commands. Besides, the execution or "not-execution" of other workflows is in the hands of GitHub and not of Action authors. :(

[gogo2464]

I did the ammend to keep a clean history with no redundant commits for version

[gogo2464]

@stefanzweifel

I removed the --amend and then I can not see if a previous commit has failure yet. Could you check out https://github.com/gogo2464/cryptatools-rs please?

[stefanzweifel]

Look, I truly don't know how to help you here.

If I understood you correctly …

• your workflow updates some files in your repository and pushes them to GitHub
• you use a personal access token as you want or MUST have protected branches. (If you don't enable protected branches, you don't need to use a PAT for git-auto-commit)
• as you use a PAT, each commit generated by git-auto-commit triggers any other workflow that listen to the push-event
• as you use a PAT, the commits would endlessly re-trigger your deploy-pypi-on-windows.yml workflow, that's why we/you added an if-clause to the job.

Now your problem is that you don't see the "current state of a potential failure in this project". What does that exactly mean?

1. Is a "potential failure" that this part of the workflow fails?
2. Is a "potential failure" that any of the other workflows fail? (https://github.com/gogo2464/cryptatools-rs/tree/master/.github/workflows)
3. Is the problem that you don't see the status-indicators of the workflow runs of the previous commit on the commit generated by git-auto-commit?
   a. Eg. you don't see the results of "windows-test", "mac-test" and "linux-test" on the commit made by git-auto-commit?

(I assume it's the last point)

I see that you've disabled the "*-test.yml" workflows, if the commit message matches the commit message generated by git-auto-commit:

• https://github.com/gogo2464/cryptatools-rs/blob/master/.github/workflows/windows-test.yml#L13
• https://github.com/gogo2464/cryptatools-rs/blob/master/.github/workflows/macos-test.yml#L13
• https://github.com/gogo2464/cryptatools-rs/blob/master/.github/workflows/linux-tests.yml#L12

This obviously blocks the workflows from running when the commit has been made by git-auto-commit and therefore you don't see the status indicators anymore.

It's not strictly necessary to block these workflows, as they don't generate commits and therefore wouldn't trigger and endless-loop. But I understand why you would do that to save CI minutes.

---

The easiest solution:

• Disable protected branches
• Remove PAT
• Use --amend and --force

---

I personally would strongly advice against using --amend --force and just generate a commit. Makes things thousand-times easier.

If I understand your project structure correctly, every time someone pushes a commit to your project, GitHub Actions will run a workflow and create another commit or rather amend to the existing commit. This will change the sha-value of the last commit and bring your local repository and remote repository out of sync. You then always have to rebase your local repository. (See recovering from upstream rebase.)

[gogo2464]

Thank you very much for your help!

Is it dangerous to allow people to disable protected branch? Everyone can currently contribute to my project.

[gogo2464]

deprecated:

I followed each step. when I do --amend and --force All the commit history is merged in a single commit.

EDIT : my bad I did not read the doc yet! https://github.com/stefanzweifel/git-auto-commit-action#advanced-uses

[stefanzweifel]

Is it dangerous to allow people to disable protected branch? Everyone can currently contribute to my project.

If you want that others can not contribute to your project, you have to make your repository private. Then only you can see the code and can make changes to it.

If your repository is public, people can fork the repository, make changes and propose the changes through pull requests. You as the maintainer of the project can than either reject the pull request or approve and merge it.

Just because a repository is public, does not mean that others can push changes directly to your repository. You would have to add users as as collaborators here to allow others to change code directly.

I personally don't use protected branches in any project (at work or in private), but they could be useful in big teams. For example you can protect the main-branch from any changes and need at least 2 code-reviews before the changes are merged.

See docs for protected branches for details: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches

[gogo2464]

My repository is public. I doubt using git auto commit action was a good idea...

Sorry for the inconvenience and thank you very very much for yout attention.

[gogo2464]

@stefanzweifel do you see what I mean?