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

Passing options to hlint-run? #20

Open
philderbeast opened this issue Oct 19, 2023 · 5 comments
Open

Passing options to hlint-run? #20

philderbeast opened this issue Oct 19, 2023 · 5 comments
Assignees

Comments

@philderbeast
Copy link

With hlint-run, I'm able to pass in folders to this action doing the equivalent of:

hlint src/

Using the action how would we pass options like --cpp-define and --cpp-simple?

hlint src/ --cpp-define=WINDOWS=1
hlint test/ --cpp-simple

https://github.com/commercialhaskell/stack/blob/af098aa6a8246960229871228c5ed757e29916ad/.github/workflows/unit-tests.yml#L24-L26

@balacij
Copy link

balacij commented Jun 14, 2024

FWIW, I got around this issue by adding them through hlint-bin, e.g., hlint-bin: hlint --hint=code/.hlint.yaml.

@mihaimaruseac
Copy link
Collaborator

I completely forgot about this one. I'll try to handle this by July 4th long weekend :)

As a side note, I'm considering deprecating hlint-{setup,run} pair in favor of https://github.com/haskell-actions/hlint-scan but I need to make sure all current users can migrate without being impacted too severely. Can you please take a look and see if you can use hlint-scan instead? Thank you!

@balacij
Copy link

balacij commented Jun 17, 2024

For my use case, I need a specific version of hlint, which makes hlint-setup particularly great for me. It doesn't look like hlint-scan is capable of the same, unfortunately.

However, it looks like hlint-scan and hlint-run have the same goal -- run HLint and report using GitHub's reporting features. They just use different reporting methods, from what I gather.

If time/cost is a concern and contributor to deprecation, I certainly wouldn't mind contributing if you can point me in the right direction.

@mihaimaruseac
Copy link
Collaborator

Thank you for the reply. Then I won't deprecate this until we can make sure hlint-scan is capable of selecting the hlint version.

@chungyc
Copy link
Member

chungyc commented Nov 3, 2024

For my own reference, is there a use case where you would want to invoke HLint in different steps with different command-line flags in a GitHub action? I.e., would there be a reason why you wouldn't want to specify the command-line flags in .hlint.yaml instead?

haskell-actions/hlint-scan intentionally does not support custom command-line flags because the presumption is that they could be specified in .hlint.yaml, and it removes the possibility of getting the flags wrong for what it needs to do. If different command-line flags are needed with the same .hlint.yaml file, then I can look into supporting it in haskell-actions/hlint-scan. One could also have separate .hlint.yaml files, but this doesn't seem great if only the command-line flags are different.

For running a custom version of HLint, haskell-actions/hlint-scan does support the binary input to specify the HLint binary, where the intention was that one could use haskell-actions/hlint-setup to download a custom binary to use if one needs to.1 Obviously I have never used this, since Docker actions turn out not to be able to use the downloaded binary. It likely could be worked around by copying the binary to the repository directory, but this is less than ideal. I will open an issue against haskell-actions/hlint-scan to figure out a way to use a binary downloaded by @actions/tool-cache.

Footnotes

  1. hlint-scan itself downloading a custom version was not considered because the convenient to use library for doing so is in JavaScript, which is not trivially usable by a Haskell binary in a Docker action, if it is at all possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants