Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Sep 14, 2023
  3. Sep 08, 2023
    • GitBot's avatar
      Integrate gitlab-ci/remove-release-name-from-deploy-target and 10 more · 3712a85c
      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
      3712a85c
  5. Sep 04, 2023
  7. Aug 31, 2023
  9. Aug 30, 2023
  11. Aug 29, 2023
  13. Aug 28, 2023
  15. Aug 25, 2023
  17. Aug 24, 2023
  19. Aug 22, 2023
    • GitBot's avatar
      Integrate gitlab-ci/add-confluence-stage and 2 more · ce65109f
      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.
      ce65109f
  21. Aug 11, 2023
  23. Aug 09, 2023
  25. Aug 08, 2023
  27. Jul 27, 2023
    • GitBot's avatar
      Integrate gitlab-ci/separate-images-in-multiple-pipelines and 1 more · d0983938
      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
      d0983938
  29. Jul 25, 2023
    • GitBot's avatar
      Integrate gitlab-ci/unify-image-and-sdk-package-jobs and 3 more · c49cb607
      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.
      c49cb607
  31. Jul 24, 2023
  33. Jul 17, 2023
    • Felix Gerking's avatar
      board:common: Temp grade detection · 5b7e1241
      Felix Gerking authored 
      Add a common function to export the current temperature grade as
environment var. The var should later be evaluated by bootscript to
set the appropriate temperature limits in the devicetree.
Enabled the temp grade export for imx8m platforms.

BCS 746-001385
      5b7e1241
  35. Jun 29, 2023
    • Dmitry Petrov's avatar
      seco-mx8[mp|mm]: Use board detection in SPL to apply board specific SSC values · 83809706
      Dmitry Petrov authored and Jonas Höppner's avatar Jonas Höppner committed 
      The 'pbb' board needs different settings, so these are applied depending
on the board detection.

BCS 746-001402
      83809706
    • Dmitry Petrov's avatar
      baseboard_util: fix board detection in SPL · 3c129085
      Dmitry Petrov authored and Jonas Höppner's avatar Jonas Höppner committed 
      The current implementation of board detection calls gpio_lookup_name() which
is not available in SPL:

    aarch64-seconorth-linux-ld.bfd: board/keithkoep/common/built-in.o: in function `baseboard_get_gpio_value':
    uboot-imx-kuk/board/keithkoep/common/baseboard_util.c:20: undefined reference to `gpio_lookup_name'
    make[1]: *** [scripts/Makefile.spl:420: spl/u-boot-spl] Error 1
    make: *** [Makefile:1865: spl/u-boot-spl] Error 2

The existing GPIO names are just simple numbers coded as strings (i.e. expanded
IMX_GPIO_NR macro):

    #define PFID_SOM_MARKER_PIN     "109"
    ...
    // SBC imx6
    #define PFID_SBC_IMX6_VERSION_BIT0    "37"
    ...
    // SBC imx8m Mini
    #define PFID_SBC_IMX8MM_VERSION_BIT0    "89"
    ...
    // SBC imx8m Plus
    #define PFID_SBC_IMX8MP_VERSION_BIT0    "102"
    ...
    // SOM imx8m
    #define PFID_SOM_VERSION_BIT0   "113"
    ...

The easiest way to fix baseboard_get_gpio_value() routine in SPL is replace
gpio_lookup_name() call with simple_strtol().
This should work if we will follow this naming convention in future.
      3c129085
  37. Jun 15, 2023