Add jq and yq packages to images

Clarifying: this originally was intended to ask for kislyuk/yq

There is mikefarah/yq however it notes it supports a smaller syntax than kislyuk/yq

ksislyuk/yq works by converting XML to JSON allowing jq to use its natural language support.

I think jq is the most common and it should be enough

The yq package adds support for XML which is likley just as important given we now have been modifying the phpunit config to support differences in core versions. As noted above yq uses jq for the parsing engine and is primarily a converter.

who can review dependencies and security consequences

A good question, to my knowledge this has not been requested before in this queue and there is no documented review policy. Given the lack of policy it would likley need to be done by a queue admin (yourself?) as none of us can speak to an undefined standard.

I mean adding yq requires to add python interpreter

The python interpreter is already on the images and is used by gitlab_templates to provision the mkdocs stage (in other words: we are not likely to accept the removal of the python interpreter anytime soon) .

with few dependencies,

Fair it may add more dependencies into python.

If there is a binary XML->JSON->XML and YAML->JSON->YAML converter that could be a reasonable alternative to the yq package.

IMO it's useless for CI image

https://git.drupalcode.org/project/gitlab_templates/-/blob/main/scripts/... is an example of where we are creating a 51 line script for what could likely be done more efficiently and reliably a 1 line yq command. I've had other discussions in Slack where we are making the jobs harder to maintain, more fragile (dependent upon another HTTP GET, and can be broken by mismatch in versions downloaded vs version of the gitlab template) (these are incidents that have occurred in the past) by using external PHP Scripts.

Downloading extra scripts is somewhat of an anti-pattern in GitLab, and the tricks that gitlab_templates team currently use do not currently exist for GitLab Components meaning the ability to inline commands can become even more important long term.

The script alone proves that we need to make changes to XML files as part of the CI process which renders the argument 'useless' as moot and only leaves 'is it worth the cost vs savings'.

As jq is instalkled as dependency here's MR

I generally recommend to be explicit.

For all we know next year yq could change and not use the jq package (highly unlikely however if they do we loose jq and don’t realize it)