[enhancement]: add automation for ubuntu/* braches to run shellcheck against changed package scripts (preinst, prerm, postrm, postinst)

[blackboxsw]

Enhancement

When debian/(pre|post)(rm|inst) scripts are modified in the current PR run shellcheck or some other tool to check that the number of POSIX shell warnings or errors is not increased by the active PR. This helps avoid POSIX shell logical errors or conditions from being introduced which could affect health of unattended-upgrades, do-release-upgrade or manual package updates by users.

Expect a non-blocking github action for this that is only run on pull requests targeting ubuntu/*

[mostafaCamel]

Doing some exploratory search

Which tool to use?

• shellcheck does indeed look like the preferred route/ tool to use
• In the shellcheck documentation, there does not seem a way to allowlist all existing errors in the base branch or even have a static file defining all specific instances (not error types) to ignore as they already existed before the introduction of shellcheck in our repo. An example of allowlisted errors to be ignored by a linting tool (in this case it was all instances of an error type names_match in given files).
• However, the shellcheck documentation recommends the use of the wrapper "Differential ShellCheck" in such cases. Fwiw, this wrapper seems to be maintained by RedHat (but with a GPL3 licence) in order to ignore already-existing errors in the base branch of the PR.

How to use the tool?

• Custom github action calling a tox command
  • tox is mainly developed for python tools. The installation of shellcheck is distro-dependent (see the Installing section in the repo's README.
• Native Github action (the binaries of both shellcheck and Differential ShellCheck are pre-installed on Github's Ubuntu runners.

For local development, I think the only route is to add in cloud-init's documentation a section on how to install shellcheck and run it locally.

For the PR check, whatever we choose it will be a native Github action.

@blackboxsw let me know what you think. I have 3 routes in mind for the PR check:

• Your suggestion: a non-blocking PR check with shellcheck. We can then create a chore issue to cleanup existing errors and eventually turn its failures into blocking the PR.

• A blocking PR check with shellcheck, especially if we know it is feasible in the short/medium term to correct already-existing errors (given that it is only 4 files per branch and the files seem quite small). However, I don't know how time-critical the PR to these ubuntu/* branches are so whether it should be ok to expect the PR authors to correct the errors as well.

• A blocking PR check with Differential Shell Check (blocking because the failures are unique to the base branch and do not occur in the source branch).

[mostafaCamel]

#6371

[mostafaCamel]

If this check is fair enough to be blocking PRs on failure, we will need to edit/add new branch protection rules in the repo settings so that failures of this check block the PR