v4.4.39

Release notes

Changes

• no change

v4.4.38

Release notes

Changes

• Fixed format_html_content (and therefore format_html_file, which the linting of a nodejs-codeunit applies to
  every html-file of that codeunit): text which belongs together was torn apart into several lines. The html-parser
  hands out the text of an element in several pieces - an ampersand which does not begin a character-reference is
  reported on its own and every character-reference is reported on its own - and the serializer wrote every piece
  into a line of its own. An angular-template with @if (a != null && b != null) { therefore ended up with the two
  ampersands on separate lines, which made the template unparsable, so the next build of that codeunit failed while
  the build which caused it still succeeded. Tom & Jerry was affected as well and lost the spaces around the
  ampersand. Pieces which belong together are joined into one text now, keeping the whitespace which was between
  them.
• ScriptCollectionCore got the functions docker_login and docker_login_with_retry (amount of attempts: 5 by
  default) and login_to_defined_docker_registries, which every docker-login of ScriptCollection goes through, uses
  the retrying one now. Reason: a docker login sporadically failed with net/http: TLS handshake timeout, which
  aborted a whole build. That timeout is hardcoded in the registry-client of the docker-daemon and can not be
  configured, so the only way to survive a temporarily slow registry is another attempt. Only timeout-errors are
  retried, because an error with a permanent cause like wrong credentials would fail again in every further attempt.
  For that, GeneralUtilities got retry_action_if, which retries an action only if the given predicate accepts the
  thrown exception; retry_action delegates to it and behaves exactly as before.

v4.4.37

Release notes

Changes

• improvement.
• start_rtsp_test_stream and create_test_stream_video got the parameter background_color. The background of a
  test-stream was fixed to black before, which a product can not change although the picture of a test-stream is what
  its testcases compare against. The default is black, so a caller which does not pass the parameter gets exactly
  the same picture as before. The value is restricted to letters, digits and the number-sign, because it is put into
  the description of the lavfi-source of ffmpeg, whose parts are separated by colons.

v4.4.36

Release notes

Changes

• Fixed run_program_argsasarray_async: the standard-output and the standard-error of the started program were connected
  to pipes of the calling process, although nobody reads the pipes of a program which is started asynchronously. Such a
  program was therefore stopped as soon as its pipe was full and terminated as soon as the calling process ended and closed
  its end of the pipe, even though it is started to outlive that process. A stream which was started by
  start_rtsp_test_stream for example died immediately when the python-process which started it ended. The standard-output
  and the standard-error of an asynchronously started program are discarded now.
• Replaced the deprecated License :: classifier in pyproject.toml with the SPDX license = "GPL-3.0-only"
  field, which removed the SetuptoolsDeprecationWarning: License classifiers are deprecated. warning that
  scbuildcodeunitsc raised while building the package.

v4.4.35

Release notes

Changes

• Implemented the dependency-update for flutter-codeunits (pub.dev) and for nodejs-codeunits (npm). Until now get_dependencies, get_available_versions and set_dependency_version of TFCPS_CodeUnitSpecific_Flutter and of TFCPS_CodeUnitSpecific_NodeJS were not implemented, so the UpdateDependencies.py of such a codeunit did nothing or aborted.
• Added TFCPS.PubDependencies and TFCPS.NpmDependencies, which read and write the dependencies of a pubspec.yaml respectively of a package.json and ask pub.dev respectively the npm-registry for the available versions of a dependency. TFCPS_CodeUnitSpecific_TypeScript uses NpmDependencies now too, because it resolves its dependencies from the same registry and in the same file-format as a nodejs-codeunit.
• The dependency-update of a flutter- and of a nodejs-codeunit writes the lock-files of the codeunit afterwards, so the package-files and the lock-files state the same versions when the update has finished.

v4.4.34

Release notes

Changes

• Updated dependencies.

v4.4.33

Release notes

Changes

• Fixed that generate_certificate_for_development_purposes_for_product generated a new TLS-certificate for development-purposes on every single run instead of keeping the existing one until it expires. The certificate-files are named after the product (<productname>DevelopmentCertificate.crt), but the check whether a certificate already exists looked for a file named after the domain (<productname>.test.local.crt), which is never written - so the check never found anything and every build of a repository which generates such a certificate replaced it. The check now uses the name under which the certificate is really written; the generated files keep their names, so nothing which refers to them (for example a Dockerfile which embeds the certificate) is affected
• Fixed that translating the xlf-files of a project stopped at the first language which the configured LibreTranslate-instance does not offer. Such an instance knows a limited set of languages while a project states the languages it wants, so a project which has one of the others ended the whole run with the error of that language - and every language behind it stayed untranslated as well, including the ones the instance knows. The languages the instance offers are asked of it now (get_supported_translation_languages), the others are skipped and reported by name, and their texts stay in the base-language, which is what the fallback of every translation-mechanism exists for
• Fixed that the testcases for the resolution of environment-variables and of the OCI-registry-credentials failed in a containerized build (scbuildcodeunits -c) although they passed in a build on the host. These testcases replaced the configuration-folder of the current user by a temporary one to become independent of the machine they run on, but the machine-wide configuration has a second source which has precedence over that folder: the configuration-file which a host mounts into a build-container. In a containerized build that mount exists, so the testcases read the real credentials of the build-machine instead of the ones they had arranged. The testcases now isolate both sources, so their result no longer depends on whether they run on a developer-machine or inside a build-container. Only the testcases are affected; the behavior of the product is unchanged

v4.4.31

Release notes

Changes

• Refactoring for using custom OCI image registries when building codeunits.

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.

v4.4.29

Release notes

Changes

• Fixed a remote build of a flutter-codeunit (android, ios, macos and windows) failing with Error when reading '/C:/tools/flutter/packages/flutter/lib/material.dart': No such file or directory for every import of a package when it was started on a machine whose flutter-package was already resolved. The archive which is sent to the task-runner contained the .dart_tool-folder of the package, whose package_config.json states the folder of every package of the app as an absolute path of the machine the build was started on, and the flutter-tool of the runner resolves the packages again only when that file is older than pubspec.yaml, so the runner compiled the app against folders which do not exist there. A build-step can now state folders whose content only applies to the machine the build was started on (folders_which_are_not_transferred of TFCPS_CodeUnitSpecific_Base.run_program_on_remote_runner respectively of TFCPS_RemoteBuild.run_program_on_runner), which are left out while the archive is packed; a flutter-codeunit states the .dart_tool-folder of its package this way. The folder is left out of the archive instead of being removed from the working-tree, because the working-tree belongs to the developer and a tool of theirs - for example the dart-extension of an ide, which resolves the packages whenever pubspec.yaml changes, which a build does - can generate it again at any moment, so removing it would only be a race against that tool
• Fixed the line-separators of a codeunit-file being converted to the ones of the current operating-system when its version was updated. TFCPS_Tools_General.write_version_to_codeunit_file passed the file to the xml-serializer by its name, which opens it in text-mode, so a build on windows rewrote every line of the file with crlf while the trailing newline (which was appended in binary-mode) stayed lf, which left the file with mixed line-separators and made every build on windows produce a diff over the whole file. The file is written through a binary file-object now, so a codeunit-file is written with lf on every operating-system