boulder (moss-format) LINT suggestions for future reference

ermo

The overarching idea is for boulder (really moss-format) to be as "up front" as possible wrt. LINT feedback in recipes.

Ideally, if while parsing, boulder finds an unknown macro, it should stop the build with a LINT message before doing anything else (assuming that partial downloads can be resumed).

Suggested LINT issues:

always use quotes for version strings (see boulder#45)
recipe uses %python actions, but doesn't specify a binary/virtual python provider in rundeps
Licenses key MUST only contain known SPDX licences
release property MUST be an integer
Empty key
Empty list
Bad characters in text fields (🧌 is currently a legal name)
Order of keys
python in run/builddeps (should be binary(python3) or virtual(python3) depending on where we end up)
description and summary have a low Damerau–Levenshtein distance after being stripped of whitespace at either end and lowercased

der_eismann

Maybe check if the license is a valid SPDX identifier. After the build we could also check if there are any .a files inside and if the license is e.g. BSD we can check if there is a license file in the package.

ermo

der_eismann Maybe check if the license is a valid SPDX identifier. After the build we could also check if there are any .a files inside and if the license is e.g. BSD we can check if there is a license file in the package.

The source directory is automatically analysed for known licenses during boulder new invocation. Any licence found is then added to the generated skeleton.

But it is a good idea to do a LINT run of the licences listed, yes.

davidjharder

Is the intent for boulder to lint for things before they are parsed and become errors?
Examples:

Empty keys/Lists,
Bad characters in text fields

Other linting candidates

Order of fields
Field "types" e.g. release is an integer

ermo

davidjharder Is the intent for boulder to lint for things before they are parsed and become errors?

The intent is to LINT while parsing the yaml files up front and report errors and then quit early, if the end result would be a failing build and/or wrong output (one example being the version string 2.10 being parsed as 2.1 for instance).

A good real world example would be a long compiler build where a typo in an install macro would lead to the build failing after 2 hours instead of failing after less than a second of recipe parsing where the unknown macro is immediately spotted and reported. We have actually seen this happen with the current tooling.

joebonrichie

summary != description - although this could be easily worked around
duplicate fields

This shouldn't necessarily be handled by the linter by rather the indexer but:

Ensure the release is 1 for new packages
Ensure the release gets bumped

W.R.T "Licenses key MUST only contain known SPDX licences" - Exception for EULA, any licences with a custom EULA should link to the EULA agreement e.g. intel-microcode, discord.

ReillyBrogan

It should be possible to flag using a tag or branch with git sources.

davidjharder

Both summary and description are not required by boulder, should they be?

davidjharder

Found boulder will error out when dependency lists have leading or trailing white space other than the expected indent

ermo

davidjharder Found boulder will error out when dependency lists have leading or trailing white space other than the expected indent

Apologies for the delay.

Could you give an example?

davidjharder

ermo

I went and looked again

indenting with tab characters makes boulder crash with "[tab character] cannot start any key". Tabs do this almost anywhere in a stone.yaml
parsing a list only fails on inconsistent indenting, a three-space indented list will be parsed, as will a four-space list; but a mixed list will error out (parse two items as one and fail to find the dep) or crash (when the last list item is the problem)

So "indent lists with exactly four spaces" could be a rule, if only to make the error more consistent and earlier