Skip to content

Conversation

@pjcj
Copy link
Contributor

@pjcj pjcj commented Dec 27, 2012

I thought it might be nice to have a link to CPANcover to show the code coverage for a module or file. I've implemented the minimal front-end. If people think the idea has merit, then there really needs to be cpan-api support to check whether CPANcover has results for the module and, ideally, to link modules to their results, wherever such results may be found (usually lib/ or blib/).

That process seemed a little more complicated (or, at least, I couldn't immediately see how to implement it) so I thought I'd solicit feedback on the general idea first.

The README commit is separate and can be applied (or not) independently.

pjcj added 2 commits December 23, 2012 17:03
This really needs support from the cpan-api to only offer the link when there are CPANcover results.
@monken
Copy link
Contributor

monken commented Dec 27, 2012

@oalders
Copy link
Member

oalders commented Dec 27, 2012

Just you. ;)

On 2012-12-27, at 11:31 AM, Moritz Onken wrote:

http://cpancover.com/latest/index.html 404? Is it just me?


Reply to this email directly or view it on GitHub.

Olaf Alders
olaf@wundersolutions.com

http://www.wundersolutions.com
http://twitter.com/wundercounter

866 503 2204 (Toll free - North America)
416 944 8306 (direct)

@oalders
Copy link
Member

oalders commented Dec 27, 2012

BTW, I think adding this link is a great idea. Should we have some JS that checks to see if the results exist for the dist before we post the link? Maybe that's too much overhead?

@monken
Copy link
Contributor

monken commented Dec 27, 2012

It could become quite annoying if the resource doesn't exist. Is there an API that we could use to incorporate the data in metacpan?

@pjcj
Copy link
Contributor Author

pjcj commented Dec 30, 2012

Unfortunately there is no API - in fact the whole site is simply static files at the moment. So I suppose you could say that the API is HEAD requests. I do have plans, but waiting for them to be implemented would be the wrong decision.

I'd be happy to implement that if I could get some pointers in the right direction. Has anyone implemented something similar that I could look at the diffs and work out what needs to happen?

@monken
Copy link
Contributor

monken commented Jan 2, 2013

We would need a script, such as https://github.com/CPAN-API/cpan-api/blob/master/lib/MetaCPAN/Script/Tickets.pm.
And you would have to add new properties to https://github.com/CPAN-API/cpan-api/blob/master/lib/MetaCPAN/Document/Distribution.pm that would hold the data. After adding properties, you wil lwant to run bin/metacpan mapping to push the changes to the ES server.
Ping me on IRC if you have questions.

@ranguard
Copy link
Member

As nothing has happened on this for a while I am closing it - but I think we all agree it would be nice to have if it can be implemented against an API or something so that the links always work

@ranguard ranguard closed this Jun 14, 2013
@pjcj
Copy link
Contributor Author

pjcj commented Jun 14, 2013

We did make some progress on this at the QA Hackathon, but didn't get things finished. I think we're at the point where we can determine what coverage is available without making a HEAD request but we don't have that hooked up to MetaCPAN at all. I'm happy to have this ticket closed as it has served its purpose and, hopefully, at some point we can get it implemented.

Thanks to everyone who contributed.

@oalders
Copy link
Member

oalders commented Jun 14, 2013

It's actually not a significant amount of work to get this into the API. I do hope we can get this implemented. :)

@pjcj
Copy link
Contributor Author

pjcj commented Jun 14, 2013

I'll mentally bump up the priority (warning: may not actually have any effect) and may well come back and bother you all for tips on IRC or something.

@oalders
Copy link
Member

oalders commented Mar 13, 2014

Am re-opening this since @pjcj and I are now in the same room. ;)

@oalders oalders reopened this Mar 13, 2014
@oalders
Copy link
Member

oalders commented Mar 15, 2014

I'm closing this in favour of #1128, which doesn't add the link to the ES index. I've done it that way because it was just easier for now. Because as releases get updated, the reports are not going to be archived at cpancover.com, we'd need to keep that in mind if putting things in ES. So, when a release gets a report, we'd need to check all previous releases to see if they have a report link and then remove the links.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

4 participants