Skip to content
Snippets Groups Projects
  1. Mar 01, 2024
  2. Feb 28, 2024
  3. Feb 23, 2024
  4. Feb 19, 2024
  5. Dec 21, 2023
  6. Nov 20, 2023
  7. Nov 17, 2023
  8. Nov 07, 2023
  9. Nov 06, 2023
    • Tobias Kahlki's avatar
      setup:genio700: Remove PACKAGE_CLASSES override · 63d9fe5c
      Tobias Kahlki authored
      We use rpm packages per default in our Yocto setup.
      Use it for MediaTek as well (different package classes provoke potential
      issues in various pre-/post-steps and also reduce reusability between
      platforms with the same arch).
      63d9fe5c
  10. Nov 03, 2023
  11. Oct 27, 2023
  12. Oct 25, 2023
  13. Oct 23, 2023
  14. Oct 20, 2023
  15. Oct 19, 2023
    • GitBot's avatar
      Integrate gitlab-ci/reverse-pipeline-cancellation-order and 6 more · 13198e9d
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@3697b4ea
      
      cancel_pipelines: reverse order of cancellation
      
      Cancel parent pipeline first before cancelling its children in order not
      to have failed parent pipelines (trigger jobs are failed if their
      downstream pipeline is cancelled).
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@5f4ca2fb
      
      cancel_pipelines: list actually cancelled (child-)pipelines
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@c80cba84
      
      Cancel all pipelines on newer commit
      
      We already canceled running pipelines before. Gitlab, however, might
      have already canceled previous pipelines automatically, but without
      canceling their child pipelines.
      Remove the "running" status filter when cancelling pipelines, so that
      also already cancelled pipelines will be included.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@84eb6e22
      
      Revert "Cancel all pipelines on newer commit"
      
      This reverts commit f7582b74e7c565d55bb8a0315fe75c4ab4385fa2.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@f7582b74
      
      Cancel all pipelines on newer commit
      
      We already canceled running pipelines before. Gitlab, however, might
      have already canceled previous pipelines automatically, but without
      canceling their child pipelines.
      Extend the mechanism now to cancel all pipelines up to and including
      "running" as well as "canceled" states.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@0ec55c07
      
      Fix list() call in update_submodule
      
      Here we don't just iterate over the results, so we have to use
      "all=True" instead of "as_list=False". See previous commit for
      explaination.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@4b3a517e
      
      Make sure to get all items on Gitlab list() calls
      
      The list() call on Gitlab classes uses pagination per default. If the
      number of items exceeds a certain limit, we only get a part of the
      results. We can pass "all=True" to the calls in order to disable
      pagination and get all results.
      If we're looping over the items, though, the recommended way of getting
      them is to use a generator object, which works calling list() with
      "as_list=False". See documentation for reference:
      
      https://python-gitlab.readthedocs.io/en/v2.10.1/api-usage.html#pagination
      
      Note: the "as_list" argument is deprecated in newer versions of the
      python-gitlab library, in favor of the newer "iterator=True":
      https://python-gitlab.readthedocs.io/en/v3.6.0/changelog.html#feature
      We are using v2.10.1 of the library, though, so this commit also updates
      calls using the new way, which is not working with our version.
      13198e9d
    • GitBot's avatar
      Integrate gitlab-ci/combine-confluence-pages-from-multiple-pipelines and 2 more · 720a98ec
      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.
      720a98ec
  16. Oct 16, 2023
  17. Oct 04, 2023
  18. Sep 28, 2023
  19. Sep 25, 2023
  20. Sep 18, 2023
  21. Sep 15, 2023
  22. Sep 14, 2023
  23. Sep 08, 2023
    • GitBot's avatar
      Integrate gitlab-ci/remove-release-name-from-deploy-target and 10 more · f1f72a4d
      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
      f1f72a4d
  24. Sep 05, 2023
  25. Sep 04, 2023
  26. Aug 31, 2023
  27. Aug 30, 2023
  28. Aug 28, 2023
  29. Aug 24, 2023
    • GitBot's avatar
      Integrate gitlab-ci/add-azure-stage · 2bab004d
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@e6808701
      
      Add "Deploy Azure" stage
      
      This stage contains jobs to deploy packaged artifacts to our Azure blob
      storage. The required variables `AZURE_STORAGE_ACCOUNT` and
      `AZURE_STORAGE_SAS_TOKEN` are stored in the GitLab CI/CD variables.
      The storage container `AZURE_CONTAINER_NAME` and artifact path
      `AZURE_TARGET_FOLDER` are passed from the parent pipeline.
      2bab004d
  30. Aug 22, 2023
    • GitBot's avatar
      Integrate gitlab-ci/add-confluence-stage and 2 more · 2324a9d6
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@f8c1d732
      
      Add confluence stage
      
      This adds two jobs to the Yocto pipeline:
      
       - generate-confluence-page
       - publish-confluence-page
      
      The first one generates a confluence page from a template
      (`confluence-page.xml.jinja2`) using information downloaded from all
      successful "Deploy FTP" jobs of the same pipeline.
      
      The second one publishes this page in Confluence and displays a link to
      the new page. If the page already exists it is overwritten.
      
      The place in Confluence where the new page is published is configurable
      via the `CONFLUENCE_SPACE` and `CONFLUENCE_PARENT_ID` variables.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@fee9493b
      
      generate-build-pipeline: re-add YAML format parsing
      
      This was accidentally forgotten in the previous commit.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@9b777f29
      
      Rename "generate_job_from_template" script to "render_jinja2_template"
      
      This makes the script more general and open for other future purposes.
      The parsing of the YAML content is conditional now, depending on the new
      "format" argument.
      2324a9d6
  31. Aug 11, 2023
  32. Jul 27, 2023
    • GitBot's avatar
      Integrate gitlab-ci/separate-images-in-multiple-pipelines and 1 more · 12405076
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@9406ad75
      
      Yocto build: separate images in multiple pipelines
      
      Instead of building the Yocto image, the Yocto SDK and the FNGSystem
      image in one single pipeline, separate them into three independent
      pipelines that are triggered in parallel.
      
      This makes the concept more modular: we have a single general pipeline
      now which is configurable from outside via variables. Hence we can have
      a custom number of pipelines along with custom build targets in each
      project without having to make code changes in the gitlab-ci project.
      
      The default Yocto manifest pipeline configures three build pipelines:
      
      - yocto-build-jobs
      - sdk-build-jobs
      - fngsystem-build-jobs
      
      In a project including the Yocto manifest pipeline, we can disable
      certain build pipelines using job rules, e.g. disabling the SDK build:
      
      sdk-build-jobs:
        rules:
          - when: never
      
      Furthermore we can add more pipelines by simply adding jobs extending
      the '.build-jobs' class in the project's .gitlab-ci.yml:
      
      yocto-custom-build-jobs:
        extends:
          - .build-jobs
        variables:
          BITBAKE_TASK: build
          CI_PARAM_IMAGE: custom-image
          CI_PARAM_DISTRO: custom-distro
          PACKAGE_TYPE: image
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@447804d2
      
      .gitlab-ci: increase analyze timeout
      12405076
  33. Jul 25, 2023
    • GitBot's avatar
      Integrate gitlab-ci/unify-image-and-sdk-package-jobs and 3 more · f76ced36
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@5762a54c
      
      Yocto build: unify image and SDK package jobs
      
      Image and SDK package jobs call the same package script just with
      different arguments. Instead of having two job classes `package_release`
      and `package_sdk` for these two tasks, merge them into the base class
      `package` and make the differences configurable via a variable
      `PACKAGE_TYPE`.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@8e72eac2
      
      Yocto build: add variable for manual builds
      
      Instead of hard-coding the rules for manual builds in each actual job,
      conditionally add this to the `buildbase` class and add a variable
      `MANUAL_BUILD` to the according jobs.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@e6d71996
      
      Yocto build: unify image and SDK build jobs
      
      Image and SDK builds share a lot of similar code. Instead of having two
      job classes `build_yocto_image` and `build_yocto_sdk` for these two
      tasks, merge them into the base class `build_yocto` and make the
      differences configurable via a variable.
      
      The `dump_install_command` part of the script, which was not executed
      for SDK builds, is always present now, but it's only executed if the
      `INSTALLSCRIPT` variable is set, which is not the case for SDK builds.
      
      The `collect_srcrevs` part of the script is executed in all cases. It
      was not part of the SDK build before, but it's not less relevant there.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@f892500f
      
      Yocto build: make main artifacts path configurable
      
      Instead of specifying all possible artifacts paths and abusing the fact
      that GitLab ignores non-existing paths during artifact upload, implement
      a cleaner solution with a configurable path.
      f76ced36
Loading