urlchecker-action
urlchecker-action copied to clipboard
Can't use action to check only dotfiles
Hey, me again :smile:
I ran urlchecker-python v0.22 on a directory with dotfiles (.editorconfig
, etc.) using this command:
urlchecker check --file-types '.*' .
That works fine.
Then I ran urlchecker-action v0.2.3, which as I understand includes the new version of the python script, with the following option:
file_types: '.*'
And the action simply skips all files and "passes" with "Done. No urls were collected."
Notably, the output of the action's build (on GitHub) says:
file types: ['.']
So I think it is removing the asterisk entirely. I tried using double quotes, using no quotes, escaping the asterisk with a backslash, and using a double-asterisk, but the result was the same each time.
Any thoughts?
Update: I got it to work if I added a second file type. So for instance using this as the option in the action works:
file_types: .md,.*
So this is more minor, then; it only fails if .*
is the only file path given.
As an aside, when using file_types: .md,.*
, the output in the action on GitHub lists, under "Found files in workspace", everything except the dotfiles, even though it does check them. I'm not sure that really matters, but for completeness I thought I'd let you know.
Did you try including the quotes in the argument for the action? It's probably mapping '.*'
to just .*
and we really want to say '".*"'
and then it's mapped to ".*"
on the command line.
As an aside, when using file_types: .md,.*, the output in the action on GitHub lists, under "Found files in workspace", everything except the dotfiles, even though it does check them. I'm not sure that really matters, but for completeness I thought I'd let you know.
That sounds like a bug we can address at urlchecker-python.
@rootwork here is a suggested fix for the missing quotes - we can ensure they always are there via the action (it seems like it would be unlikely the user would provide them in the step specification!) https://github.com/urlstechie/urlchecker-action/pull/77
Yeah, I tried all of the following:
file_types: .*
file_types: '.*'
file_types: ".*"
file_types: '.\*'
file_types: '.**'
in the .yml
action-workflow file.
That's a good test to add though.
I think you’d need the double quotes for the action, the first set (whatever they are) will be removed. You can also just test the PR I opened action (via its branch).
OK, but I definitely tried file_types: ".*"
and it definitely didn't work...
Oh or do you mean file_types: ''.*''
(i.e. two apostrophes rather than one quote-mark)?
Two sets of quotes, one single one double like ‘“.*”’
We are essentially quoting the quotes.
Ah I understand now. I tried it and no go -- results in "No urls collected".
I tried both file_types: ["'.*'"]
and file_types: ['".*"']
.
In both cases the output in the GitHub action was identical -- i.e. file types: ["'.*'"]
for the first and file types: ['".*"']
for the second.
Meaning, if I'm understanding it correctly, that single quotes get stripped, but double quotes both get preserved. Strange!
Hmm, the last thing I'd try is the branch I created (without any special quotes). If that doesn't work, we'll need to rethink this.
OK -- will have to try tomorrow.
After running a bunch of tests, I realized that the *
after the .
is only recognized if some pattern precedes it.
By writing the pattern twice or adding a ,
, as an alternative, you can make it work. It is not beautiful but it works. ".*,.*"
, '.*,.*'
, ",.*"
, ',.*'
, ".*,"
and '.*,'
should work. @rootwork can you please test these and confirm?
@vsoch I think this issue is related to the python library input parsing urlchecker-python/urlchecker/client/check.py#L51. You can also take a look at some of my tests with the new version here.
I tried '.*,'
and I can confirm that that works.
In regards to the omitted items in "Found files in workspace" @vsoch mentioned above, that may be an issue with urlchecker-python, but it only shows up in the GitHub action output (it's not a part of the python script's output).
should we try something different here or is the workaround okay? Should we just add this pattern to the docs perhaps for others to easily find?
I don't mind using the workaround, and if you add it to the docs then it becomes official and no longer a workaround, right? 😄
Haha, indeed! Here is a suggested addition: https://github.com/urlstechie/urlchecker-action/pull/97