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

Wildcard expansion can affect INPUT_FILE_PATTERN before it's passed to git status/add #153

Closed
ryandy opened this issue Apr 8, 2021 · 7 comments
Labels
bug Something isn't working

Comments

@ryandy
Copy link

ryandy commented Apr 8, 2021

Version of the Action
v4.9.2

Describe the bug
If INPUT_FILE_PATTERN contains a wildcard, the shell will attempt to expand it to the name(s) of matching files if they exist. This list of filenames will then be passed to git status and git add as part of _git_is_dirty() and _add_files(), instead of the originally specified string. The list of files (obtained from shell globbing) can differ from the list of files that would have matched using git pathspec.

To Reproduce

  1. Start with a repo with two files:
.
├── package
│   └── module.py
└── setup.py
  1. Modify package/module.py
  2. Run git-auto-commit-action with a file_pattern input of "*.py".
  3. See output message of "Working tree clean. Nothing to commit". This is because the shell expanded INPUT_FILE_PATTERN from "*.py" to "setup.py" before passing it to git status. Because setup.py was not modified, git status will report no change.

Expected behavior
git status should report that package/module.py was modified. And then git add should add package/module.py.

Possible fix
Running set -o noglob in entrypoint.sh will turn off glob file expansion. This could probably be run at the top of the script, but could also be run in a more local, targeted fashion, so long as it covers both the call to git status and git add.

@stefanzweifel
Copy link
Owner

Thanks for reporting!

I think instead of setting set -o noglob it would probably be better to quote the $INPUT_FILE_PATTERN. What do you think?

For some reason I've deliberately disabled the shellcheck for these calls. (Can't remember why)

@stefanzweifel stefanzweifel added the bug Something isn't working label Apr 8, 2021
@ryandy
Copy link
Author

ryandy commented Apr 8, 2021

Hey Stefan, thanks for the quick response.

Quoting was also my first thought, but I don't think quoting will work in the case of specifying 2+ pathspecs, e.g.:

  file_pattern: "*.txt *.py"

I think if you were to quote $INPUT_FILE_PATTERN in this case, git would interpret it as a single pathspec with a space in the middle.

@stefanzweifel
Copy link
Owner

@ryandy Howdy, I've created a PR in #154 which would solve this problem. I've decided to add a new option called disable_globbing to prevent the shell from expanding the filenames.

Would be great if you could update your workflow like seen below and report, if this solution solves your problem.

-- uses: stefanzweifel/git-auto-commit-action@v4
+- uses: stefanzweifel/git-auto-commit-action@fixes/153
+    with:
+      disable_globbing: true

(As mentioned in the PR, I don't feel comfortable disabling globbing for all users. 🤷 )

@ryandy
Copy link
Author

ryandy commented Apr 11, 2021

I tested it out, and that works for me. Thanks for pulling this together!

@stefanzweifel
Copy link
Owner

I've just tagged a new minor version which includes the disable_globbing option: v4.10.0.

I will close this issue now. Thanks again for reporting this!

@spookylukey
Copy link

spookylukey commented Nov 2, 2021

Do you think disable_globbing: true should be the default instead?

I just spent several hours tracking down why this action no longer seemed to be working in my repo, when:

  • it was definitely working before
  • I had pinned all versions of all actions
  • nothing else relevant had changed in the workflow.

It turns out someone added something.yml to the root of the repo, and from then on all changes to other */*.yml made by my linters were no longer being seen. This is a fairly nasty gotcha!

@stefanzweifel
Copy link
Owner

@spookylukey Thanks for bringing this up again. Sorry that you wasted hours on this issue :/

When I've added disable_globbing in #154 I've deliberately didn't make it the default as this StackOverflow answer made by nervous that it could break other stuff.

Wouldn't be something I would change in a minor version but something that we could consider doing in v5. (I currently don't have big plans for this Action, as it works great for my use case – and for many others too. I still have a private note where I collect improvements and changed that could be made in v5. Added this to the list)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants