v4.4.30

Release notes

Changes

• Fixed scpreparebuildpipelineforgitlab and scpreparebuildpipelineforgithub not checking out the branch the pipeline runs for. The runner checks out the commit in a detached-head-state, and the generated branch-name pipeline_<timestamp> which was used in that case does not tell the versioning which branch is built, so a repository had to check the branch out itself in its pipeline-configuration before calling the command. Doing that with git checkout -b makes the whole job fail with fatal: a branch named '<branch>' already exists as soon as the runner reuses the build-directory of a previous pipeline-run of the same branch, because a git clean removes untracked files but no branch-refs. The branch-name is taken from the environment-variable of the ci-system now (CI_COMMIT_REF_NAME for gitlab respectively GITHUB_REF_NAME for github) and the branch is checked out with git checkout -B, which also works if the branch already exists, so the pipeline-configuration of a repository must not do this anymore
• Fixed that the build of a docker-codeunit did not log in to the registries which are defined for the machine before it started docker buildx build. The base-image of a Dockerfile is resolved by buildkit and not by ScriptCollection, so a base-image which comes from a registry that is not publicly readable made the build fail with failed to resolve source metadata [...] 401 Unauthorized although the credentials were configured. The same gap existed in docker_pull, which relied on the login being done by whatever resolved the address of the image before. Both log in themselves now
• Added that every image which a repository declares in .ScriptCollection/OCIImages/ImageDefinition.csv is passed to the build of a docker-codeunit as the build-argument image_<imagename in lowercase>, whose value is the address with tag the image has to be taken from on this machine (the same name under which an image is available to the local test-services). A Dockerfile has to declare its base-image with it (ARG image_debian followed by FROM ${image_debian}) instead of writing a registry-address into its FROM-line, because an address inside the Dockerfile is resolved by buildkit and therefore neither uses the custom registry which is preferred on this machine nor the fallback-registry of the repository
• The machine-wide credentials-file ~/.ScriptCollection/GlobalCache/RegistryCredentials.csv is mounted read-only into the build-container of a locally started container-build now (to /Workspace/ScriptCollectionConfiguration/RegistryCredentials.csv), analogous to the image-registries-file. Until now a build in a container could only use a registry which requires authentication when its credentials were declared as environment-variables, because the configuration-folder inside the container belongs to the container-user. The credentials of both sources are still used together
• Fixed the documentation of the configuration-folder claiming that everything which accesses a registry logs in beforehand, which was not true for the image-build and for docker_pull, and that the credentials-file is never exposed to the build-container

Migration

Every repository which has a docker-codeunit whose Dockerfile takes its base-image from a registry has to replace the address in the FROM-line by the build-argument of that image, for example ARG image_debian and FROM ${image_debian} for an image which is declared as Debian in .ScriptCollection/OCIImages/ImageDefinition.csv. A FROM-line which keeps a literal address still builds, but it ignores the custom registry of the machine as well as the fallback-registry.