[cocoapods] fix Metric regexes

[chris48s]

There are a couple of cocoapods tests failing because the package we are testing against has been getting 0 downloads/week (how sad 😞 ) and the isMetricOverTimePeriod regex didn't allow 0/week. In principle though, it should also be valid to have 0 open issues + so on, so I've changed the others

[shields-ci]

	Messages
📖	✨ Thanks for your contribution to Shields, @chris48s!

Generated by 🚫 dangerJS

[PyvesB]

I do see one potential issue with the revised regexes: "numbers" with leading zeros will now be valid, for instance 000002/week would pass, which is a bit strange. Maybe something along the lines of (0|[1-9][0-9]*) would do the trick?

[chris48s]

good call - cheers

[RedSparr0w]

Changes look good 👍

[RedSparr0w]

Could you update this comment too.

[chris48s]

Hmm.. Now you've pointed out this comment, I've gone and looked back at the history. I probably should have done this before submitting this PR:

It looks like this was introduced in response to a particular problem, where an error condition was manifesting as a zero value: #1201

That seems like a bit of an edge case, but I now wonder if there are other cases like this I'm not thinking of 🤔

So maybe would be better to leave the regexes requiring a non-zero value and just switch this test to a more active repo. Then I tried to find one and realised that while the badge is correctly reporting the number from the CocoaPods API, CocoaPods seems to be incorrectly reporting all (or many) packages as having zero downloads per week. For example, this is one of the most popular packages on cocoapods: http://cocoapods.org/pods/Alamofire its unlikely that this has really had >300,000 downloads this month with 0 of them in the last week. This seems to be a reported issue which has been open for some time :/

[RedSparr0w]

Would we be better to show an error message rather than 0?
Although it won't always be valid, neither will 0 and if it is actually 0, it would be less likely to go noticed that the message is incorrect.

[platan]

@chris48s good investigation. #1201 was a really ugly bug.
@RedSparr0w 0 is OK for me, better than unavailable. Stats are available and are equal 0.

In my opinion this kind of bugs can be avoided when we have tests which stubs and verifies exact value.
What do you think about replacing tests for weekly downloads and weekly apps with?

t.create('downloads (valid, weekly)')
  .get('/dw/AFNetworking.json')
  .intercept(nock => nock('https://metrics.cocoapods.org')
    .get('/api/v1/pods/AFNetworking')
    .reply(200, { stats: { download_week: 2 }}))
  .expectJSON({
    name: 'downloads',
    value: '2/week'
  });

t.create('apps (valid, weekly)')
  .get('/aw/AFNetworking.json')
  .intercept(nock => nock('https://metrics.cocoapods.org')
    .get('/api/v1/pods/AFNetworking')
    .reply(200, { stats: { app_week: 2 }}))
  .expectJSON({
    name: 'apps',
    value: '2/week'
  });

[chris48s]

Having chewed this over a bit, I think the best solution here is to:

• Keep hitting the live endpoint in tests
• Specifically allow 0 in the regex for cocoapods weekly downloads to account for this condition
• More generally require >0 in the metric regexes to avoid allowing unwanted bugs to creep in