Skip to content
Snippets Groups Projects
  1. Oct 19, 2023
    • GitBot's avatar
      Integrate gitlab-ci/combine-confluence-pages-from-multiple-pipelines and 2 more · e8b7b21b
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@c292d144
      
      Confluence: combine data from parallel child pipelines
      
      We deploy Yocto image and SDK in different pipelines, which both have
      their Confluence jobs with the same Confluence target. Previously these
      pipelines have been independent, so that running the Confluence job in
      one of them would overwrite the Confluence page if it has been run in
      the other pipeline before. Hence we could either have the image files or
      the SDK files in the Confluence page.
      Combine these now by checking for other parallel child pipelines with
      the same Confluence configuration, so that running the Confluence jobs
      in the Yocto pipeline also includes the information from the SDK build
      and vice versa.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@53106170
      
      Fix ci-test SDK version
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@d6d4ab61
      
      Fix ci-test SDK download
      
      Since the implementation of multiple child pipelines we cannot use the
      previous artifacts download links anymore specifying tag and job name,
      because the jobs for image build and SDK build are equal. Use direct
      download links instead via job number.
      e8b7b21b
  2. Oct 16, 2023
  3. Sep 28, 2023
  4. Sep 25, 2023
  5. Sep 18, 2023
  6. Sep 15, 2023
  7. Sep 14, 2023
  8. Sep 08, 2023
    • GitBot's avatar
      Integrate gitlab-ci/remove-release-name-from-deploy-target and 10 more · e92deb64
      GitBot authored
      --
      
      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
      e92deb64
  9. Sep 04, 2023
  10. Aug 28, 2023
  11. Aug 25, 2023
  12. Feb 24, 2023
Loading