Allow most printable ASCII chars for service label key

[kb2ma]

Description

Updated the regex for valid characters for a service label to allow printable ASCII chars except space, double/single quotes, and backtick. These extended characters support apps like Traefik and caddy-docker-proxy. Characters still not supported likely are not useful as label keys and error prone.

Fixes #1949

Type of change

patch

How Has This Been Tested?

Updated 06-validation.spec.ts. Also tested by POSTing all valid chars to /v2/local/target-state.

[cywang117]

This LGTM! Do you have to add Closes: #1949 in the commit footer for bulldozer-bot to auto-close the issue on merge? Or is having it in the PR description sufficient? Since I'm not sure, I'd suggest adding it to the commit footer just in case.

[dfunckt]

Unless the Supervisor assigns labels to containers/volumes/etc. and balena-engine rejects them, it doesn't really need to validate them.

I think this in fact applies in general: data that only ever comes from the target state will necessarily be valid because tooling (eg. the CLI, builder, API, etc.) will have rejected invalid releases before they make it to the Supervisor.

[kb2ma]

Unless the Supervisor assigns labels to containers/volumes/etc. and balena-engine rejects them, it doesn't really need to validate them.

But the accepted character set on an older Supervisor version may not include characters from a newer balena-builder or balena-cli. So in a sense the Supervisor is acting as the guardian of the device. It knows best what the device should accept.

cc: @pipex

[pipex]

I agree with Ken, even though there are some validations on the CLI and backend, the user may be using an incompatible CLI version, so the supervisor should still do some validations (without going too crazy).

The supervisor also exposes the target-state endpoint that allows to bypass the CLI entirely, so validation is needed there for sure.

[dfunckt]

But the accepted character set on an older Supervisor version may not include characters from a newer balena-builder or balena-cli.

@kb2ma from a user’s perspective this will appear as failure to deploy a release. The correct way to introduce breaking changes is via contracts. Let’s chat in JF how to go about doing that.

@pipex I wasn’t aware about that endpoint but my point still stands, validation should happen in that endpoint and ideally using the same primitives/code the CLI and builder use.

[kb2ma]

@balena-ci I self-certify!