Open phrfpeixoto opened 4 months ago
it makes sense, as coverage doesn't run in your env but in the action's own dockerized env.
This caused #370 in the past, and the only way forward I'd see would be doing #347 (which is likely quite some work).
Do you have a better idea?
The best option would be to allow custom package installation, through one of the options set on the action. The entrypoint script would check for that, and install them on demand.
This would probably lead to a slower action start for users of this feature. It's not a problem per se, but let's keep that in mind.
Also, I imagine we'd soon have people requesting the ability to install custom apt packages because they need them for the python packages etc.
I wonder if there could be a way to select a custom base image instead...
That's actually a good call. Why don't we update the base image to include the top 10 most used coverage.py plugins?
Do you want to compare the current base image with, say, what it would be if we installed the plugins advertised in the coverage lib? I'm ok going this way this if this doesn't add more than 30% to the size of the image (gotta put the threshold somewhere).
(haha we're featured on that page, I didn't know that 😅)
I'll try to have a look on that this weekend.
Is there any way to support coverage plugins?
My
.coveragerc
file uses thedjango_coverage_plugin
pluginAnd I get this error when running the workflow: