Add report-file argument

[WesleyKlop]

When trying to use this action on one of my projects I ran into the issue where the action could not find the coverage file, this fixes that

[franciscodua]

Hi @WesleyKlop
Thanks for this amazing PR! I bet it will be useful to many people using it.
As an extra, could you just update the README to make it clear that we now have a new workflow option?

That would help people with the same needs find the solution much quicker.

[WesleyKlop]

Ofcourse, I'll add it this weekend :)

[andreaTP]

Hi @WesleyKlop I hope I'm in time to avoid wasting your time!
Although we really appreciate your effort we decided to have a more generic approach to the problem in order to avoid re-binding all the option's matrix of the codacy-coverage-reporter tool.

On the bright side I'm going to test out and eventually merge this WIP:
#12
totally based on your approach.

Thanks a lot for your effort, very much appreciated!

[WesleyKlop]

Hi @WesleyKlop I hope I'm in time to avoid wasting your time!
Although we really appreciate your effort we decided to have a more generic approach to the problem in order to avoid re-binding all the option's matrix of the codacy-coverage-reporter tool.

That's okay!

On the bright side I'm going to test out and eventually merge this WIP:
#12
totally based on your approach.

Thanks a lot for your effort, very much appreciated!

No problem! Isn't this what open source is about? :)

I did look into the other PR but can't it be argued that it's better to be explicit as to what options you're providing the users? That way there's also less possibility of making mistakes, with the downside of having more maintenance of this action.

Also, a bit off-topic but I hope that's okay, I was wondering why the docker image always downloads a new version of the codacy script instead of it being embedded at build time? This way the functionality of the docker container is not consistent and predictable.

Anyway thanks for the comments and I hope to be able to use a newer version for my projects soon!

[andreaTP]

@WesleyKlop thanks for the comments!
Caching the reporter in the Docker image is a great suggestion tracked here: #13

You are correct into being explicit in the action, the reason is that we would need to map the entire matrix of arguments of the tool to cover all the use cases, creating as well a strong inter-dependency in between the two projects without much instruments to keep them aligned other than manual sync.
That's why we decided to go down the road of a less maintenance approach.

[WesleyKlop]

Alright, I understand! Maybe there is a middle ground somewhere to be found (like the type of action and flags as different parameters) as that might lead to better self-documentation and readability! (thinking about things like partial reports)

Thanks you for all the information I really appreciate it :D

[andreaTP]

Maybe there is a middle ground somewhere to be found

Sadly we failed to find it but we remain completely open to listen possible proposals!

We love to hear from our users and your feedback is super-appreciated!

[franciscodua]

Hi @WesleyKlop
We just added a similar parameter to the one you proposed. You can check it in this PR.
You can find the latest release for this action here.

Now you can just send a list of reports using a comma separated list of paths to reports

[WesleyKlop]

Hi @WesleyKlop
We just added a similar parameter to the one you proposed. You can check it in this PR.
You can find the latest release for this action here.

Now you can just send a list of reports using a comma separated list of paths to reports

That's great, thanks! :)