diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 4faddcbf61f..22a25025152 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -3,6 +3,7 @@ variables: DEFAULT_TAG: "" MIRROR_DOCKER: docker.io + LAB_ONLY: "" SJG_LAB: "" PLATFORM: linux/amd64,linux/arm64 GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_RUNNER_ID/$CI_CONCURRENT_ID/u-boot @@ -28,7 +29,10 @@ stages: stage: test.py retry: 2 # QEMU may be too slow, etc. rules: - - when: always + - if: $LAB_ONLY != "1" + when: always + - if: $LAB_ONLY == "1" + when: never before_script: - git config --global --add safe.directory "${CI_PROJECT_DIR}" # qemu_arm64_lwip_defconfig is the same as qemu_arm64 but with NET_LWIP enabled. @@ -117,7 +121,10 @@ stages: .world_build: stage: world build rules: - - when: always + - if: $LAB_ONLY != "1" + when: always + - if: $LAB_ONLY == "1" + when: never build all 32bit ARM platforms: extends: .world_build @@ -197,7 +204,10 @@ build all other platforms: .testsuites: stage: testsuites rules: - - when: always + - if: $LAB_ONLY != "1" + when: always + - if: $LAB_ONLY == "1" + when: never check for new CONFIG symbols outside Kconfig: extends: .testsuites @@ -602,10 +612,13 @@ coreboot test.py: .lab_template: &lab_dfn stage: sjg-lab + needs: [] rules: - - if: $SJG_LAB == "1" + - if: $SJG_LAB == $ROLE || $SJG_LAB == "1" when: always - - if: $SJG_LAB != "1" + - if: $SJG_LAB != "" && $SJG_LAB != "1" && $SJG_LAB != $ROLE + when: never + - if: $SJG_LAB == "" when: manual allow_failure: true dependencies: [] @@ -614,6 +627,11 @@ coreboot test.py: # Environment: # SRC - source tree # OUT - output directory for builds + - if [[ -n ${SJG_LAB} ]]; then + if [[ "${SJG_LAB}" != "${ROLE}" && "${SJG_LAB}" != "1" ]]; then + exit 0; + fi; + fi - export SRC="$(pwd)" - export OUT="${SRC}/build/${BOARD}" - export PATH=$PATH:~/bin diff --git a/doc/build/docker.rst b/doc/build/docker.rst index 5896dd5ac4a..ca3d1402b3e 100644 --- a/doc/build/docker.rst +++ b/doc/build/docker.rst @@ -1,5 +1,7 @@ -GitLab CI / U-Boot runner container -=================================== +U-Boot runner container +======================= + +See also :doc:`/develop/ci_testing`. In order to have a reproducible and portable build environment for CI we use a container for building in. This means that developers can also reproduce the CI environment, to a large degree at least, locally. This file is located in the tools/docker directory. diff --git a/doc/develop/ci_testing.rst b/doc/develop/ci_testing.rst index ffaacedc3d8..7382005d944 100644 --- a/doc/develop/ci_testing.rst +++ b/doc/develop/ci_testing.rst @@ -40,7 +40,24 @@ then the "Checks" tab will show the results. GitLab CI Pipelines ------------------- -This pipeline is defined in the top-level ``.gitlab-ci.yml`` file. Currently, +`Gitlab `_ is used for building and testing U-Boot. There +are two separate instances: + + - `Denx `_ - main tree, including custodian trees + - `Concept `_ - concept tree + +This pipeline is defined in the top-level ``.gitlab-ci.yml`` file. + +To push to Gitlab without triggering a pipeline use: + +.. code-block:: bash + + git push -o ci.skip + +Denx +~~~~ + +Currently with the main tree, we support running GitLab CI pipelines only for custodians, due to the resources the project has available. For Custodians, it is a matter of enabling the pipeline feature in your project repository following the standard @@ -50,11 +67,14 @@ runners you are able to provide. While it is intended to be able to run this pipeline on the free public instances provided at https://gitlab.com/ a problem with our squashfs tests currently prevents this. -To push to Gitlab without triggering a pipeline use: +Concept +~~~~~~~ -.. code-block:: bash - - git push -o ci.skip +Contributors can request a login at `U-Boot Concept `_ +(after sending an email to Simon Glass as shown there). +Contributors are then able to push branches and trigger a CI run. The +``.gitlab-ci.yml`` is slightly different from the main tree and CI runs +are generally twice as fast to complete. Docker container ---------------- @@ -74,3 +94,31 @@ developing features. In that case, it can be useful as part of your own testing cycle to edit these pipelines in separate local commits to pair them down to just the jobs you're interested in. These changes must be removed prior to submission. + +Using the lab +------------- + +There is an 'sjg' lab connected to gitlab. By default, this is set to run +manually, so you must click a button in the gitlab interface to kick off a run. + +You can control this behaviour by passing variables with your `git push` +command. + +To skip CI altogether (assuming your remote is called `ci` and the branch is +`feature`):: + + git push ci -o ci.skip + +To request that the lab runs:: + + git push ci -o ci.variable=SJG_LAB=1 + +To request that *only* the lab runs:: + + git push ci -o ci.variable=SJG_LAB=1 ci.variable=LAB_ONLY=1 + +To request running on just a particular board in the lab, e.g. `snow`:: + + git push ci -o ci.variable=SJG_LAB=snow + +The `LAB_ONLY` and `SJG_ONLY` options can be specified together. diff --git a/test/hooks/bin/okaro b/test/hooks/bin/okaro new file mode 120000 index 00000000000..70f831593fb --- /dev/null +++ b/test/hooks/bin/okaro @@ -0,0 +1 @@ +ellesmere/ \ No newline at end of file