Configure renovate for apk, gem, cargo, pip and npm dependencies

[bdovaz]

• I have configured renovate for apk, gem, cargo, pip and npm.
• As there are some dependencies that were added as “core” in build.py I have moved the definition to constants.py and edited renovate.json5 to add a new regular expression very similar to the previous ones.
• I had to change how various types of ARG are generated in Dockerfile because now there were problems with the multi-stage/layer build and I had to solve problems that depending on the scope I was in, certain ARG didn't exist.
• I have changed it to try to expand the cli_docker_image_version parameter, since it is a special case that instead of ARG (image generation time), it uses it in execution and requires that ENV expanded.
• I have had to downgrade eslint from 9.x to 8.x because there is some other package that required that library to be in 8.x. This problem did not occur when the dependencies were not pinned because I imagine that npm would be “smart” in that sense and would be able to establish which one is the right one.
• Since there are many libraries that are used between different linters through different descriptors, I have used a more or less objective and consistent {PACKAGE_SYSTEM]_{PACKAGE_NAME}_VERSION criterion. Examples: APK_ICU_LIBS_VERSION, NPM_ESLINT_VERSION, ...
• There are several repology libraries (apk) that in Alpine 3.21 did not exist and I had to remove them. I don't understand why when they were not pinned it didn't complain that they didn't exist.

I do not know if I have left something without pinning but there are so many things that has been a huge work.... I would appreciate help after merging this PR in case I have left something... Some of them were difficult to detect as the ones added through build.py were more hidden.

[github-actions]

🦙 MegaLinter status: ⚠️ WARNING

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ API	spectral	1		0	1.78s
⚠️ BASH	bash-exec	6		1	0.03s
✅ BASH	shellcheck	6		0	0.24s
✅ BASH	shfmt	6	0	0	1.27s
✅ COPYPASTE	jscpd	yes		no	2.86s
✅ DOCKERFILE	hadolint	129		0	60.82s
✅ JSON	jsonlint	20		0	0.2s
✅ JSON	v8r	22		0	14.86s
⚠️ MARKDOWN	markdownlint	267	0	302	23.53s
✅ MARKDOWN	markdown-table-formatter	267	0	0	174.48s
⚠️ PYTHON	bandit	214		66	3.92s
✅ PYTHON	black	214	0	0	4.81s
✅ PYTHON	flake8	214		0	1.94s
✅ PYTHON	isort	214	0	0	1.42s
✅ PYTHON	mypy	214		0	11.59s
✅ PYTHON	pylint	214		0	19.62s
✅ PYTHON	ruff	214	0	0	0.72s
✅ REPOSITORY	checkov	yes		no	42.12s
✅ REPOSITORY	git_diff	yes		no	0.48s
⚠️ REPOSITORY	grype	yes		24	13.89s
✅ REPOSITORY	secretlint	yes		no	10.43s
✅ REPOSITORY	trivy	yes		no	19.68s
✅ REPOSITORY	trivy-sbom	yes		no	0.62s
⚠️ REPOSITORY	trufflehog	yes		1	55.74s
✅ SPELL	cspell	717		0	13.32s
⚠️ SPELL	lychee	349		30	8.88s
✅ XML	xmllint	3	0	0	0.84s
✅ YAML	prettier	160	0	0	3.8s
✅ YAML	v8r	102		0	33.26s
✅ YAML	yamllint	161		0	3.55s

See detailed report in MegaLinter reports

[bdovaz]

I have had to downgrade eslint from 9.x to 8.x because there is some other package that required that library to be in 8.x. This problem did not occur when the dependencies were not pinned because I imagine that npm would be “smart” in that sense and would be able to establish which one is the right one.

This is too impacting. It's not fine with me. The configuration format changed, and users have already adapted if they updated. We had some issues filed in this summer if I'm not mistaken, and some community member helped out a bit. You could take a look if you'd.

Wow, what a nice PR , bringing us closer to "bring your own flavor" that we'll build someday :)

Agreed with @echoix , can't downgrade eslint ^^

@nvuillam @echoix about this eslint 9.x vs 8.x topic...

I have been testing and I would say that we were already on 8.x even if you think we were on 9.x....

Look:

With this Dockerfile:

FROM python:3.12.8-alpine3.21

RUN apk add --no-cache \
                npm=10.9.1-r0 \
                nodejs-current=23.2.0-r1

ENV NODE_OPTIONS="--max-old-space-size=8192" \
    NODE_ENV=production

WORKDIR /node-deps
RUN npm --no-cache install --ignore-scripts --omit=dev \
                eslint \
                eslint-config-airbnb

RUN npm ls

The result of npm ls is:

#8 [5/5] RUN npm ls
#8 1.044 (node:1) ExperimentalWarning: CommonJS module /usr/lib/node_modules/npm/node_modules/debug/src/node.js is loading ES Module /usr/lib/node_modules/npm/node_modules/supports-color/index.js using require().
#8 1.044 Support for loading ES Module in require() is an experimental feature and might change at any time
#8 1.044 (Use `node --trace-warnings ...` to show where the warning was created)
#8 1.197 node-deps@ /node-deps
#8 1.197 ├── [email protected]
#8 1.197 └── [email protected]
#8 1.197
#8 DONE 1.3s

And instead with this Dockerfile:

FROM python:3.12.8-alpine3.21

RUN apk add --no-cache \
                npm=10.9.1-r0 \
                nodejs-current=23.2.0-r1

ENV NODE_OPTIONS="--max-old-space-size=8192" \
    NODE_ENV=production

WORKDIR /node-deps
RUN npm --no-cache install --ignore-scripts --omit=dev \
                [email protected] \
                [email protected]

RUN npm ls

It does not work:

#7 1.731 npm error code ERESOLVE
#7 1.732 npm error ERESOLVE unable to resolve dependency tree
#7 1.732 npm error
#7 1.734 npm error While resolving: undefined@undefined
#7 1.734 npm error Found: [email protected]
#7 1.734 npm error node_modules/eslint
#7 1.734 npm error   eslint@"9.19.0" from the root project
#7 1.734 npm error
#7 1.734 npm error Could not resolve dependency:
#7 1.734 npm error peer eslint@"^7.32.0 || ^8.2.0" from [email protected]
#7 1.734 npm error node_modules/eslint-config-airbnb
#7 1.734 npm error   eslint-config-airbnb@"19.0.4" from the root project
#7 1.734 npm error
#7 1.734 npm error Fix the upstream dependency conflict, or retry
#7 1.734 npm error this command with --force or --legacy-peer-deps
#7 1.734 npm error to accept an incorrect (and potentially broken) dependency resolution.

Which is why I was telling you that I had to downgrade from 9.x to 8.x, although as I show you, it is not really a downgrade but we were already on 8.x.

And without pinning it seems that by installing N dependencies in a single command it is “smart” in the sense that it is able to calculate which maximum version of each dependency it can install based on the dependencies/requirements of the rest. And it calculated: 8.x

[echoix]

Does that mean that we don't have the same eslint versions in our different images?

But anyways, in that case, I agree with you for the downgrade (if it is what the users already have). So, after publishing the patch release, it could be ok to merge this PR. I know it's a lot of work

[bdovaz]

Does that mean that we don't have the same eslint versions in our different images?

This is the conclusion that I have come to, which is more dangerous because it depends on the flavor that you use, it may solve a different version of a package as in this case.

With this PR we are sure that all will have exactly the same version.

cc @nvuillam

[echoix]

Maybe removing a plugin is less disruptive if the version in a major flavor is higher

[bdovaz]

Ready to merge!

cc @nvuillam @echoix

[echoix]

Are you available soon if it doesn't work as expected ? Are you ready for it to be merged?

[echoix]

I'd go all in and adjust accordingly.

[bdovaz]

Ready!