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

Can't use action to check only dotfiles #76

Open
rootwork opened this issue Feb 11, 2021 · 20 comments · May be fixed by urlstechie/urlchecker-python#52
Open

Can't use action to check only dotfiles #76

rootwork opened this issue Feb 11, 2021 · 20 comments · May be fixed by urlstechie/urlchecker-python#52
Labels
bug Something isn't working

Comments

@rootwork
Copy link

Hey, me again 😄

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?

@rootwork
Copy link
Author

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.

@rootwork
Copy link
Author

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.

@rootwork rootwork changed the title Can't check dotfiles with action Can't use action to check only dotfiles Feb 11, 2021
@vsoch
Copy link
Collaborator

vsoch commented Feb 11, 2021

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.

@vsoch
Copy link
Collaborator

vsoch commented Feb 11, 2021

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.

@vsoch
Copy link
Collaborator

vsoch commented Feb 11, 2021

@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!) #77

@rootwork
Copy link
Author

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.

@vsoch
Copy link
Collaborator

vsoch commented Feb 11, 2021

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).

@rootwork
Copy link
Author

OK, but I definitely tried file_types: ".*" and it definitely didn't work...

@rootwork
Copy link
Author

rootwork commented Feb 11, 2021

Oh or do you mean file_types: ''.*'' (i.e. two apostrophes rather than one quote-mark)?

@vsoch
Copy link
Collaborator

vsoch commented Feb 11, 2021

Two sets of quotes, one single one double like ‘“.*”’

@vsoch
Copy link
Collaborator

vsoch commented Feb 11, 2021

We are essentially quoting the quotes.

@rootwork
Copy link
Author

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!

@vsoch
Copy link
Collaborator

vsoch commented Feb 11, 2021

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.

@rootwork
Copy link
Author

OK -- will have to try tomorrow.

@SuperKogito
Copy link
Member

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.

@rootwork
Copy link
Author

I tried '.*,' and I can confirm that that works.

@rootwork
Copy link
Author

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).

@SuperKogito SuperKogito added the bug Something isn't working label Feb 12, 2021
@vsoch
Copy link
Collaborator

vsoch commented Jul 24, 2022

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?

@rootwork
Copy link
Author

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? 😄

@vsoch
Copy link
Collaborator

vsoch commented Jul 25, 2022

Haha, indeed! Here is a suggested addition: #97

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

Successfully merging a pull request may close this issue.

3 participants