Skip to content

Integrate gitlab-ci/remove-release-name-from-deploy-target and 10 more

GitBot requested to merge integrate/gitlab-ci/remove-release-name-from-deploy-target/into/main into main

Commit: seco-ne/yocto/infrastructure/gitlab-ci@f2a29f53

Refactoring: remove RELEASE_NAME from deploy targets

Append it to the configured target at the deploy class level instead. This removes the need for eval'ing the variables before usage. RELEASE_NAME can be used directly at the class level because it is known from build-version.env.

This makes the deploy behavior identical to the Azure stage.

--

Commit: seco-ne/yocto/infrastructure/gitlab-ci@e136e5e2

Remove top-level "release" folder from package

--

Commit: seco-ne/yocto/infrastructure/gitlab-ci@1d5e479f

Define MACHINE variable on job level

Instead of passing MACHINE from stage to stage or loading it from testdata.json, use the original value from the Jinja2 loop and set it directly for each job where it is used.

--

Commit: seco-ne/yocto/infrastructure/gitlab-ci@cdd47023

Introduce separate variables to set RELEASE_NAME and RELEASE_VERSION

The expressions to calculate RELEASE_NAME and RELEASE_VERSION cannot be stored within these variables themseselves. If set on the trigger level, they would override the calculated values in build-version.env then, as trigger variables always have the highest precedence.

Use separate variables RELEASE_VERSION_EXPRESSION and RELEASE_NAME_EXPRESSION to define how RELEASE_VERSION and RELEASE_NAME are calculated instead.

--

Commit: seco-ne/yocto/infrastructure/gitlab-ci@372d192b

Use RELEASE_VERSION and RELEASE_NAME from build-version job

Instead of passing these variables from stage to stage or regenerating their values in later stages, use the ones set in the build-version job at all places.

--

Commit: seco-ne/yocto/infrastructure/gitlab-ci@cad30c20

Remove RELEASE_SUFFIX variable

The RELEASE_NAME variable can be set directly now, so there's no need to have a dedicated RELEASE_SUFFIX anymore. A previous configuration like

RELEASE_SUFFIX: "-custom"

can now be achieved using:

RELEASE_NAME: "Yocto-${RELEASE_VERSION}-custom"

--

Commit: seco-ne/yocto/infrastructure/gitlab-ci@922f49f8

Add yocto version job

This adds a machine-independent job "build-version" which populates the RELEASE_VERSION and RELEASE_NAME variables, so that following jobs can use these without depending on the various build jobs. The variables can be set from the trigger job in a project's .gitlab-ci.yml file. They are eval'ed before saving them to version.env, so we can use deferred variable expansion or even command execution to construct their values. This mechanism is already used for the Flash-N-Go System variables.

--

Commit: seco-ne/yocto/infrastructure/gitlab-ci@073ae81e

LAVA: rename MACHINE to LAVA_MACHINE

Rename variable in order to avoid confusion with the original MACHINE variable used everywhere else. Also rename the local Jinja2 variable to include an underscore to make naming consistent.

--

Commit: seco-ne/yocto/infrastructure/gitlab-ci@a91baa55

Clean build.env before writing

This had been accidentally removed in 5e36715ef6cf98df4c1b98fedddc0c3c50ed4040.

--

Commit: seco-ne/yocto/infrastructure/gitlab-ci@1860ca8e

Remove LOG_PREFIX variable

This was used in times when the same code was executed from different places. We don't do that anymore, so the variable is obsolete.

--

Commit: seco-ne/yocto/infrastructure/gitlab-ci@3d2dbe4d

Documentation: update job generation chapter

Merge request reports