Can we encourage use of YAML schema?

I’ve no idea if this should be an RFC on GitHub or not. Seeing as it falls into my usual category of ‘half-baked ideas’, a discussion forum seems the best place for it.

Could we encourage maintainers of resources and tasks to create YAML schema?

The ritual of figuring out what params are acceptable on a resource is laughable to an outsider. Having to explain this to new Concourse users is mildly embarassing.

  1. Write some YAML
  2. Realise you need a resource
  3. Go to browser
  4. Search for resource
  5. Find right fork of resource in results
  6. Click result
  7. Scroll down to ‘example usage’
  8. Copy
  9. Go back to editor
  10. Paste
  11. Realise you need another property, rinse and repeat
  12. Set pipeline
  13. Run pipeline
  14. Pipeline doesn’t work as expected
  15. Realise that you’ve got a typo in a param that fly can’t validate, so resource didn’t work properly
  16. Headbutt desk

This isn’t something that could be solved with unilateral action, but with additional features in Concourse combined with a convention, we could make people’s lives easier.

Resource authors could write YAML schema, and make these publicly accessible. When images are pushed to a registry, the schema could either be attached as a base-64-encoded label, or perhaps a URL could be provided to the schema (what about airgapped envs?). When set-pipeline is performed, Concourse optionally reaches out for these schema and validates the provided pipeline against them. The VS Code plugin and other linters could presumably do the same thing.

I’m not quite sure how it could work for tasks, but just solving this for resources would reduce the number of errors made substantially. Given that a misconfigured Concourse resource could wreak havoc (let’s face it, we use Concourse to do important things in prod), perhaps we should be more defensive?

In before “schemas are for boomers”.

1 Like

Broadly, my view is: yes please.

I think the schemata could be directly embedded as a file in container images.