[REUSE] Add service badges

[tapanchudasama7]

This PR fixes issue #4365.

[shields-ci]

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

Generated by 🚫 dangerJS against 413f7a0

[chris48s]

thanks for having a look at this

[chris48s]

This is looking great now. Only one final thing to address and we are done:

In the service tests the reason we run integration tests against live APIs is because we use so many external services, we want tests that fail if the upstream API goes away or makes some change that we need to respond to. We run them all once a day. We will never notice this stuff otherwise. So for this reason we usually want to accept a range of valid values in the live tests. i.e: if github.com/fsfe/reuse-tool becomes non-compliant at some point in futre, it doesn't mean this code is broken - it just means something in this project we are using for testing changed.

Becuase the input values and output values are the same, lets pull out

const isReuseCompliance = Joi.string()
  .valid('compliant', 'non-compliant', 'checking', 'unregistered')
  .required()

into reuse-compliance-helper.js

and then use it in the schema:

const responseSchema = Joi.object({
  status: isReuseCompliance,
}).required()

and to validate the response in the integration test:

t.create('valid repo')
  .get('/github.com/fsfe/reuse-tool.json')
  .expectBadge({
    label: 'reuse',
    message: isReuseCompliance,
  })

and then you could either add another mocked service test for the valid case, or you could just write a small unit test for the helper function in a reuse-compliance-helper.spec.js instead of doing it with mocked HTTP calls in the service tests. I'll leave it with you...

[tapanchudasama7]

Yeah! That is a nice observation! I'll make these changes.

[chris48s]

Thanks for your first contribution 👍