kumquat-buildroot/support/misc/gitlab-ci.yml.in

155 lines
4.3 KiB
YAML
Raw Normal View History

stages:
- download
- test
gitlab-ci: fix pipelines When gitlab prepares a job to run, it checks out the repository with a non-root user, and spawns a container that runs as root, with some UID mapping that makes the files be owned by root in the container. However, our pipelines run as a nont-root user. Commit bde165f7ad (.gitlab-ci.yml: update Docker image to use) updated the docker image that is used to run in our pipelines. That new image includes a git version that is stricter about the ownership of the git tree it is acting in: git aborts in error when the user running it does not own the repository. We use `git ls-tree` quite a lot in our check-{flake8,package,symbols} rules, so they all fail (in various ways). To fix this, we either need to fix the ownership or tell git to ignore the situation. It is most probably impossible to change the ownership of the files: we run as non-root,and the files belong to root (in the container). So we're stuck. The alternative, is to do as git suggest, and tell it to ignore the situation. In a local setup, this would be very insecure, but in the pipelines, this is in a throw-away container, where a single user exists and is running, so we don't care much (if at all). Add a global before_script that registers the git config to ignore ownership issues in the buildroot repository; see [0] for the definition of the CI_PROJECT_DIR variable. Note: unlike what is said in there, and in [1], the value actually seen in CI_PROJECT_DIR is already prefixed with CI_BUILDS_DIR (the documentation is unclear about that point). [0] https://docs.gitlab.com/ee/ci/variables/predefined_variables.html [1] https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2023-02-07 22:33:12 +01:00
before_script:
- git config --global --add safe.directory ${CI_PROJECT_DIR}
.check-check-package_base:
stage: test
script:
- python3 -m pytest -v utils/checkpackagelib/
utils/check-symbols: new script This script checks for inconsistencies on symbols declared in Config.in and used in .mk files. Currently it checks only symbols following the pattern BR2_\w+ . The script first gets the list of all files in the repository (using git ls-files like 'make check-flake8' already do). Then it parses all relevant files, searching for symbol definitions and usages, and add entries into a database. At the end, the database is searched for inconsistencies: - symbol that is part of "choice" and is referenced with "select"; - legacy symbol being referenced in packages; - legacy symbol being redefined in packages; - symbol referenced but not defined; - symbol defined but not referenced; - legacy symbol that has a Note stating it is referenced by a package (for legacy handling) but is referenced in the package without a comment "# legacy"; - legacy symbol that has a Note stating it is referenced by a package but it is not actually referenced. There is also a debug parameter --search that dumps any filename or symbol entries from the database that matches a regexp. Sample usages: $ utils/check-symbols $ utils/docker-run utils/check-symbols $ utils/check-symbols --search 'GETTEXT\b|\/openssl' At same time the script is created: - add unit tests for it, they can be run using: utils/docker-run python3 -m pytest -v utils/checksymbolslib/ - add two more GitLab CI jobs: check-symbols (to check current tree using the script) and check-check-symbols (to check the script against its unit tests) Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> [Peter: print warnings to stderr, rename change_current_dir() to change_to_top_dir()] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2022-11-27 14:07:39 +01:00
.check-check-symbol_base:
stage: test
utils/check-symbols: new script This script checks for inconsistencies on symbols declared in Config.in and used in .mk files. Currently it checks only symbols following the pattern BR2_\w+ . The script first gets the list of all files in the repository (using git ls-files like 'make check-flake8' already do). Then it parses all relevant files, searching for symbol definitions and usages, and add entries into a database. At the end, the database is searched for inconsistencies: - symbol that is part of "choice" and is referenced with "select"; - legacy symbol being referenced in packages; - legacy symbol being redefined in packages; - symbol referenced but not defined; - symbol defined but not referenced; - legacy symbol that has a Note stating it is referenced by a package (for legacy handling) but is referenced in the package without a comment "# legacy"; - legacy symbol that has a Note stating it is referenced by a package but it is not actually referenced. There is also a debug parameter --search that dumps any filename or symbol entries from the database that matches a regexp. Sample usages: $ utils/check-symbols $ utils/docker-run utils/check-symbols $ utils/check-symbols --search 'GETTEXT\b|\/openssl' At same time the script is created: - add unit tests for it, they can be run using: utils/docker-run python3 -m pytest -v utils/checksymbolslib/ - add two more GitLab CI jobs: check-symbols (to check current tree using the script) and check-check-symbols (to check the script against its unit tests) Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> [Peter: print warnings to stderr, rename change_current_dir() to change_to_top_dir()] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2022-11-27 14:07:39 +01:00
script:
- python3 -m pytest -v utils/checksymbolslib/
.check-DEVELOPERS_base:
stage: test
script:
- utils/get-developers -v
.check-package_base:
stage: test
script:
- make check-package
utils/check-symbols: new script This script checks for inconsistencies on symbols declared in Config.in and used in .mk files. Currently it checks only symbols following the pattern BR2_\w+ . The script first gets the list of all files in the repository (using git ls-files like 'make check-flake8' already do). Then it parses all relevant files, searching for symbol definitions and usages, and add entries into a database. At the end, the database is searched for inconsistencies: - symbol that is part of "choice" and is referenced with "select"; - legacy symbol being referenced in packages; - legacy symbol being redefined in packages; - symbol referenced but not defined; - symbol defined but not referenced; - legacy symbol that has a Note stating it is referenced by a package (for legacy handling) but is referenced in the package without a comment "# legacy"; - legacy symbol that has a Note stating it is referenced by a package but it is not actually referenced. There is also a debug parameter --search that dumps any filename or symbol entries from the database that matches a regexp. Sample usages: $ utils/check-symbols $ utils/docker-run utils/check-symbols $ utils/check-symbols --search 'GETTEXT\b|\/openssl' At same time the script is created: - add unit tests for it, they can be run using: utils/docker-run python3 -m pytest -v utils/checksymbolslib/ - add two more GitLab CI jobs: check-symbols (to check current tree using the script) and check-check-symbols (to check the script against its unit tests) Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> [Peter: print warnings to stderr, rename change_current_dir() to change_to_top_dir()] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2022-11-27 14:07:39 +01:00
.check-symbol_base:
stage: test
utils/check-symbols: new script This script checks for inconsistencies on symbols declared in Config.in and used in .mk files. Currently it checks only symbols following the pattern BR2_\w+ . The script first gets the list of all files in the repository (using git ls-files like 'make check-flake8' already do). Then it parses all relevant files, searching for symbol definitions and usages, and add entries into a database. At the end, the database is searched for inconsistencies: - symbol that is part of "choice" and is referenced with "select"; - legacy symbol being referenced in packages; - legacy symbol being redefined in packages; - symbol referenced but not defined; - symbol defined but not referenced; - legacy symbol that has a Note stating it is referenced by a package (for legacy handling) but is referenced in the package without a comment "# legacy"; - legacy symbol that has a Note stating it is referenced by a package but it is not actually referenced. There is also a debug parameter --search that dumps any filename or symbol entries from the database that matches a regexp. Sample usages: $ utils/check-symbols $ utils/docker-run utils/check-symbols $ utils/check-symbols --search 'GETTEXT\b|\/openssl' At same time the script is created: - add unit tests for it, they can be run using: utils/docker-run python3 -m pytest -v utils/checksymbolslib/ - add two more GitLab CI jobs: check-symbols (to check current tree using the script) and check-check-symbols (to check the script against its unit tests) Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> [Peter: print warnings to stderr, rename change_current_dir() to change_to_top_dir()] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2022-11-27 14:07:39 +01:00
script:
- utils/check-symbols
.defconfig_check:
stage: test
script:
gitlab-ci: don't use before_script in job templates When gitlab prepares a job to run, it checks out the repository with a non-root user, and spawns a container that runs as root, with some UID mapping that makes the files be owned by root in the container. However, our pipelines run as a nont-root user. Commit bde165f7ad (.gitlab-ci.yml: update Docker image to use) updated the docker image that is used to run in our pipelines. That new image includes a git version that is stricter about the ownership of the git tree it is acting in: git aborts in error when the user running it does not own the repository. We use `git ls-tree` quite a lot in our check-{flake8,package,symbols} rules, so they all fail (in various ways). To fix this, we either need to fix the ownership or tell git to ignore the situation. In either case, we'll need to run a scriptlet before all our jobs. Gitlab-ci allows to provide a global before_script, that is inherited by all jobs. However, some of our jobs already declare a before_script, and that would shadow the global before_script. There is no technical reason to do our before_script separately from the actual script, so we move the code from the before_scripts to the corresponding scripts. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2023-02-07 22:33:11 +01:00
- DEFCONFIG_NAME=$(echo ${CI_JOB_NAME} | sed -e 's,_check$,,g')
- echo "Configure Buildroot for ${DEFCONFIG_NAME}"
- make ${DEFCONFIG_NAME}
- support/scripts/check-dotconfig.py .config configs/${DEFCONFIG_NAME}
artifacts:
when: on_failure
expire_in: 2 weeks
paths:
- .config
.run_make: &run_make
|
make O=${OUTPUT_DIR} > >(tee build.log |grep '>>>') 2>&1 || {
echo 'Failed build last output'
tail -200 build.log
exit 1
}
.gitlab-ci.yml: add trigger per job Triggering a single defconfig or runtime test job can be handy: - when adding or changing a defconfig; - when adding or changing a runtime test case; - when fixing some bug on a use case tested by a runtime test case. Currently there are 3 subsets of jobs that can easily be triggered by pushing a temporary branch with specific suffix: - to trigger only the check-* jobs: $ git push gitlab HEAD:<name> # currently 4 jobs - to trigger all defconfigs and all check-* jobs: $ git push gitlab HEAD:<name>-defconfigs # currently 197 jobs - to trigger all runtime tests and all check-* jobs: $ git push gitlab HEAD:<name>-runtime-tests # currently 118 jobs When the user wants to trigger a single defconfig or runtime test job, hand-editing the .gitlab-ci.yml and creating a temporary commit are currently needed. Add 2 more subsets that can be triggered based on the name of the branch pushed. - to trigger one defconfig job: $ git push gitlab HEAD:<name>-<defconfig name> # currently 1 jobs - to trigger one runtime job: $ git push gitlab HEAD:<name>-<test case name> # currently 1 jobs The check-* jobs are fast, so there is no need to add a per job trigger for them. Also, they are anyway triggered with every push already. While adding those new triggers, use the full name of the job as suffix. This leads to large branch names: $ git push gitlab HEAD:test1-tests.toolchain.test_external.TestExternalToolchainBuildrootuClibc $ git push gitlab HEAD:test2-olimex_a20_olinuxino_lime_legacy_defconfig But those branches are temporary, and this way the user doesn't need to think much, just copy and paste the job name as suffix. The hidden keys that now hold the commonalities between jobs does not hold only a script anymore, so rename then from *_script to *_base. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> [Arnout: squash two patches] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-04-08 05:22:54 +02:00
.defconfig_base:
stage: test
gitlab-ci: don't use before_script in job templates When gitlab prepares a job to run, it checks out the repository with a non-root user, and spawns a container that runs as root, with some UID mapping that makes the files be owned by root in the container. However, our pipelines run as a nont-root user. Commit bde165f7ad (.gitlab-ci.yml: update Docker image to use) updated the docker image that is used to run in our pipelines. That new image includes a git version that is stricter about the ownership of the git tree it is acting in: git aborts in error when the user running it does not own the repository. We use `git ls-tree` quite a lot in our check-{flake8,package,symbols} rules, so they all fail (in various ways). To fix this, we either need to fix the ownership or tell git to ignore the situation. In either case, we'll need to run a scriptlet before all our jobs. Gitlab-ci allows to provide a global before_script, that is inherited by all jobs. However, some of our jobs already declare a before_script, and that would shadow the global before_script. There is no technical reason to do our before_script separately from the actual script, so we move the code from the before_scripts to the corresponding scripts. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2023-02-07 22:33:11 +01:00
script:
- DEFCONFIG_NAME=${CI_JOB_NAME}
- OUTPUT_DIR=output
.gitlab-ci.yml: add trigger per job Triggering a single defconfig or runtime test job can be handy: - when adding or changing a defconfig; - when adding or changing a runtime test case; - when fixing some bug on a use case tested by a runtime test case. Currently there are 3 subsets of jobs that can easily be triggered by pushing a temporary branch with specific suffix: - to trigger only the check-* jobs: $ git push gitlab HEAD:<name> # currently 4 jobs - to trigger all defconfigs and all check-* jobs: $ git push gitlab HEAD:<name>-defconfigs # currently 197 jobs - to trigger all runtime tests and all check-* jobs: $ git push gitlab HEAD:<name>-runtime-tests # currently 118 jobs When the user wants to trigger a single defconfig or runtime test job, hand-editing the .gitlab-ci.yml and creating a temporary commit are currently needed. Add 2 more subsets that can be triggered based on the name of the branch pushed. - to trigger one defconfig job: $ git push gitlab HEAD:<name>-<defconfig name> # currently 1 jobs - to trigger one runtime job: $ git push gitlab HEAD:<name>-<test case name> # currently 1 jobs The check-* jobs are fast, so there is no need to add a per job trigger for them. Also, they are anyway triggered with every push already. While adding those new triggers, use the full name of the job as suffix. This leads to large branch names: $ git push gitlab HEAD:test1-tests.toolchain.test_external.TestExternalToolchainBuildrootuClibc $ git push gitlab HEAD:test2-olimex_a20_olinuxino_lime_legacy_defconfig But those branches are temporary, and this way the user doesn't need to think much, just copy and paste the job name as suffix. The hidden keys that now hold the commonalities between jobs does not hold only a script anymore, so rename then from *_script to *_base. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> [Arnout: squash two patches] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-04-08 05:22:54 +02:00
- echo "Configure Buildroot for ${DEFCONFIG_NAME}"
- make ${DEFCONFIG_NAME}
- ./support/scripts/check-dotconfig.py .config ./configs/${DEFCONFIG_NAME}
- echo 'Build buildroot'
- *run_make
- |
./support/scripts/boot-qemu-image.py "${DEFCONFIG_NAME}" > >(tee runtime-test.log) 2>&1 || {
echo 'Failed runtime test last output'
tail -200 runtime-test.log
exit 1
}
retry:
max: 2
when:
- runner_system_failure
- stuck_or_timeout_failure
artifacts:
when: always
expire_in: 2 weeks
paths:
- .config
- build.log
- output/images/
- output/build/build-time.log
- output/build/packages-file-list.txt
- output/build/*/.config
- runtime-test.log
.gitlab-ci.yml: add trigger per job Triggering a single defconfig or runtime test job can be handy: - when adding or changing a defconfig; - when adding or changing a runtime test case; - when fixing some bug on a use case tested by a runtime test case. Currently there are 3 subsets of jobs that can easily be triggered by pushing a temporary branch with specific suffix: - to trigger only the check-* jobs: $ git push gitlab HEAD:<name> # currently 4 jobs - to trigger all defconfigs and all check-* jobs: $ git push gitlab HEAD:<name>-defconfigs # currently 197 jobs - to trigger all runtime tests and all check-* jobs: $ git push gitlab HEAD:<name>-runtime-tests # currently 118 jobs When the user wants to trigger a single defconfig or runtime test job, hand-editing the .gitlab-ci.yml and creating a temporary commit are currently needed. Add 2 more subsets that can be triggered based on the name of the branch pushed. - to trigger one defconfig job: $ git push gitlab HEAD:<name>-<defconfig name> # currently 1 jobs - to trigger one runtime job: $ git push gitlab HEAD:<name>-<test case name> # currently 1 jobs The check-* jobs are fast, so there is no need to add a per job trigger for them. Also, they are anyway triggered with every push already. While adding those new triggers, use the full name of the job as suffix. This leads to large branch names: $ git push gitlab HEAD:test1-tests.toolchain.test_external.TestExternalToolchainBuildrootuClibc $ git push gitlab HEAD:test2-olimex_a20_olinuxino_lime_legacy_defconfig But those branches are temporary, and this way the user doesn't need to think much, just copy and paste the job name as suffix. The hidden keys that now hold the commonalities between jobs does not hold only a script anymore, so rename then from *_script to *_base. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> [Arnout: squash two patches] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-04-08 05:22:54 +02:00
.runtime_test_download:
stage: download
# Keep test-dl directory so the downloaded files can be an artifact of
# the job passed to all jobs of next stages.
script: ./support/testing/run-tests -d test-dl/ --prepare-only
artifacts:
when: always
paths:
- test-dl/
.gitlab-ci.yml: add trigger per job Triggering a single defconfig or runtime test job can be handy: - when adding or changing a defconfig; - when adding or changing a runtime test case; - when fixing some bug on a use case tested by a runtime test case. Currently there are 3 subsets of jobs that can easily be triggered by pushing a temporary branch with specific suffix: - to trigger only the check-* jobs: $ git push gitlab HEAD:<name> # currently 4 jobs - to trigger all defconfigs and all check-* jobs: $ git push gitlab HEAD:<name>-defconfigs # currently 197 jobs - to trigger all runtime tests and all check-* jobs: $ git push gitlab HEAD:<name>-runtime-tests # currently 118 jobs When the user wants to trigger a single defconfig or runtime test job, hand-editing the .gitlab-ci.yml and creating a temporary commit are currently needed. Add 2 more subsets that can be triggered based on the name of the branch pushed. - to trigger one defconfig job: $ git push gitlab HEAD:<name>-<defconfig name> # currently 1 jobs - to trigger one runtime job: $ git push gitlab HEAD:<name>-<test case name> # currently 1 jobs The check-* jobs are fast, so there is no need to add a per job trigger for them. Also, they are anyway triggered with every push already. While adding those new triggers, use the full name of the job as suffix. This leads to large branch names: $ git push gitlab HEAD:test1-tests.toolchain.test_external.TestExternalToolchainBuildrootuClibc $ git push gitlab HEAD:test2-olimex_a20_olinuxino_lime_legacy_defconfig But those branches are temporary, and this way the user doesn't need to think much, just copy and paste the job name as suffix. The hidden keys that now hold the commonalities between jobs does not hold only a script anymore, so rename then from *_script to *_base. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> [Arnout: squash two patches] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-04-08 05:22:54 +02:00
.runtime_test_base:
stage: test
# Keep build directories so the rootfs can be an artifact of the job. The
# runner will clean up those files for us.
# Multiply every emulator timeout by 10 to avoid sporadic failures in
# elastic runners.
.gitlab-ci.yml: add trigger per job Triggering a single defconfig or runtime test job can be handy: - when adding or changing a defconfig; - when adding or changing a runtime test case; - when fixing some bug on a use case tested by a runtime test case. Currently there are 3 subsets of jobs that can easily be triggered by pushing a temporary branch with specific suffix: - to trigger only the check-* jobs: $ git push gitlab HEAD:<name> # currently 4 jobs - to trigger all defconfigs and all check-* jobs: $ git push gitlab HEAD:<name>-defconfigs # currently 197 jobs - to trigger all runtime tests and all check-* jobs: $ git push gitlab HEAD:<name>-runtime-tests # currently 118 jobs When the user wants to trigger a single defconfig or runtime test job, hand-editing the .gitlab-ci.yml and creating a temporary commit are currently needed. Add 2 more subsets that can be triggered based on the name of the branch pushed. - to trigger one defconfig job: $ git push gitlab HEAD:<name>-<defconfig name> # currently 1 jobs - to trigger one runtime job: $ git push gitlab HEAD:<name>-<test case name> # currently 1 jobs The check-* jobs are fast, so there is no need to add a per job trigger for them. Also, they are anyway triggered with every push already. While adding those new triggers, use the full name of the job as suffix. This leads to large branch names: $ git push gitlab HEAD:test1-tests.toolchain.test_external.TestExternalToolchainBuildrootuClibc $ git push gitlab HEAD:test2-olimex_a20_olinuxino_lime_legacy_defconfig But those branches are temporary, and this way the user doesn't need to think much, just copy and paste the job name as suffix. The hidden keys that now hold the commonalities between jobs does not hold only a script anymore, so rename then from *_script to *_base. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> [Arnout: squash two patches] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-04-08 05:22:54 +02:00
script:
gitlab-ci: don't use before_script in job templates When gitlab prepares a job to run, it checks out the repository with a non-root user, and spawns a container that runs as root, with some UID mapping that makes the files be owned by root in the container. However, our pipelines run as a nont-root user. Commit bde165f7ad (.gitlab-ci.yml: update Docker image to use) updated the docker image that is used to run in our pipelines. That new image includes a git version that is stricter about the ownership of the git tree it is acting in: git aborts in error when the user running it does not own the repository. We use `git ls-tree` quite a lot in our check-{flake8,package,symbols} rules, so they all fail (in various ways). To fix this, we either need to fix the ownership or tell git to ignore the situation. In either case, we'll need to run a scriptlet before all our jobs. Gitlab-ci allows to provide a global before_script, that is inherited by all jobs. However, some of our jobs already declare a before_script, and that would shadow the global before_script. There is no technical reason to do our before_script separately from the actual script, so we move the code from the before_scripts to the corresponding scripts. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2023-02-07 22:33:11 +01:00
- TEST_CASE_NAME=${CI_JOB_NAME}
.gitlab-ci.yml: add trigger per job Triggering a single defconfig or runtime test job can be handy: - when adding or changing a defconfig; - when adding or changing a runtime test case; - when fixing some bug on a use case tested by a runtime test case. Currently there are 3 subsets of jobs that can easily be triggered by pushing a temporary branch with specific suffix: - to trigger only the check-* jobs: $ git push gitlab HEAD:<name> # currently 4 jobs - to trigger all defconfigs and all check-* jobs: $ git push gitlab HEAD:<name>-defconfigs # currently 197 jobs - to trigger all runtime tests and all check-* jobs: $ git push gitlab HEAD:<name>-runtime-tests # currently 118 jobs When the user wants to trigger a single defconfig or runtime test job, hand-editing the .gitlab-ci.yml and creating a temporary commit are currently needed. Add 2 more subsets that can be triggered based on the name of the branch pushed. - to trigger one defconfig job: $ git push gitlab HEAD:<name>-<defconfig name> # currently 1 jobs - to trigger one runtime job: $ git push gitlab HEAD:<name>-<test case name> # currently 1 jobs The check-* jobs are fast, so there is no need to add a per job trigger for them. Also, they are anyway triggered with every push already. While adding those new triggers, use the full name of the job as suffix. This leads to large branch names: $ git push gitlab HEAD:test1-tests.toolchain.test_external.TestExternalToolchainBuildrootuClibc $ git push gitlab HEAD:test2-olimex_a20_olinuxino_lime_legacy_defconfig But those branches are temporary, and this way the user doesn't need to think much, just copy and paste the job name as suffix. The hidden keys that now hold the commonalities between jobs does not hold only a script anymore, so rename then from *_script to *_base. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> [Arnout: squash two patches] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-04-08 05:22:54 +02:00
- echo "Starting runtime test ${TEST_CASE_NAME}"
- |
./support/testing/run-tests -o test-output/ -d test-dl/ -k --timeout-multiplier 10 ${TEST_CASE_NAME} || {
echo 'Failed runtime test last output'
if [ -f test-output/*-run.log ]; then
tail -200 test-output/*-run.log | sed 's/\r\r$//'
else
tail -200 test-output/*-build.log
fi
exit 1
}
retry:
max: 2
when:
- runner_system_failure
- stuck_or_timeout_failure
artifacts:
when: always
expire_in: 2 weeks
paths:
- test-output/*.log
- test-output/*/.config
- test-output/*/images/*
.gitlab-ci.yml: add trigger per job Triggering a single defconfig or runtime test job can be handy: - when adding or changing a defconfig; - when adding or changing a runtime test case; - when fixing some bug on a use case tested by a runtime test case. Currently there are 3 subsets of jobs that can easily be triggered by pushing a temporary branch with specific suffix: - to trigger only the check-* jobs: $ git push gitlab HEAD:<name> # currently 4 jobs - to trigger all defconfigs and all check-* jobs: $ git push gitlab HEAD:<name>-defconfigs # currently 197 jobs - to trigger all runtime tests and all check-* jobs: $ git push gitlab HEAD:<name>-runtime-tests # currently 118 jobs When the user wants to trigger a single defconfig or runtime test job, hand-editing the .gitlab-ci.yml and creating a temporary commit are currently needed. Add 2 more subsets that can be triggered based on the name of the branch pushed. - to trigger one defconfig job: $ git push gitlab HEAD:<name>-<defconfig name> # currently 1 jobs - to trigger one runtime job: $ git push gitlab HEAD:<name>-<test case name> # currently 1 jobs The check-* jobs are fast, so there is no need to add a per job trigger for them. Also, they are anyway triggered with every push already. While adding those new triggers, use the full name of the job as suffix. This leads to large branch names: $ git push gitlab HEAD:test1-tests.toolchain.test_external.TestExternalToolchainBuildrootuClibc $ git push gitlab HEAD:test2-olimex_a20_olinuxino_lime_legacy_defconfig But those branches are temporary, and this way the user doesn't need to think much, just copy and paste the job name as suffix. The hidden keys that now hold the commonalities between jobs does not hold only a script anymore, so rename then from *_script to *_base. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> [Arnout: squash two patches] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-04-08 05:22:54 +02:00
utils/test-pkg: add gitlab-ci support The gitlab-ci support in test-pkg allows to parallelize the test-pkg work into several gitlab jobs. It's much faster than local serialized testing. To trigger this, a developer will have to add, in the latest commit of their branch, a token on its own line, followed by a configuration fragment, e.g.: test-pkg config: SOME_OPTION=y # OTHER_OPTION is not set SOME_VARIABLE="some value" This configuration fragment is used as input to test-pkg. To be able to generate one job per test to run, we need the list of tests in the parent pipeline, and the individual .config files (one per test) in the child pipeline. We use the newly-introduced --prepare-only mode to test-pkg, and collect all the generated .config files as artefacts; those are inherited in the child pipeline via the "needs::pipeline" and "needs::job" directives. This is a bit tricky, and is best described by the Gitlab-CI documentation [0]. We also list those .config files to generate the actual list of jobs to run in the child pipeline. Notes: - if the user provides an empty fragment, this is considered an error: indeed, without a fragment (and the package name), there is no way to know what to test; - if that fragment yields an empty list of tests, then there is nothing to test either, so that is also considered an error. [0] https://docs.gitlab.com/ee/ci/yaml/README.html#artifact-downloads-to-child-pipelines Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [yann.morin.1998@free.fr: - split the change to test-pkg to its own patch - generate the actual yml snippet in support/scripts/generate-gitlab-ci-yml, listing the .config files created by test-pkg - some code-style-candies... ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-08-21 15:46:46 +02:00
.test_pkg:
stage: test
utils/test-pkg: add gitlab-ci support The gitlab-ci support in test-pkg allows to parallelize the test-pkg work into several gitlab jobs. It's much faster than local serialized testing. To trigger this, a developer will have to add, in the latest commit of their branch, a token on its own line, followed by a configuration fragment, e.g.: test-pkg config: SOME_OPTION=y # OTHER_OPTION is not set SOME_VARIABLE="some value" This configuration fragment is used as input to test-pkg. To be able to generate one job per test to run, we need the list of tests in the parent pipeline, and the individual .config files (one per test) in the child pipeline. We use the newly-introduced --prepare-only mode to test-pkg, and collect all the generated .config files as artefacts; those are inherited in the child pipeline via the "needs::pipeline" and "needs::job" directives. This is a bit tricky, and is best described by the Gitlab-CI documentation [0]. We also list those .config files to generate the actual list of jobs to run in the child pipeline. Notes: - if the user provides an empty fragment, this is considered an error: indeed, without a fragment (and the package name), there is no way to know what to test; - if that fragment yields an empty list of tests, then there is nothing to test either, so that is also considered an error. [0] https://docs.gitlab.com/ee/ci/yaml/README.html#artifact-downloads-to-child-pipelines Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [yann.morin.1998@free.fr: - split the change to test-pkg to its own patch - generate the actual yml snippet in support/scripts/generate-gitlab-ci-yml, listing the .config files created by test-pkg - some code-style-candies... ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-08-21 15:46:46 +02:00
script:
gitlab-ci: don't use before_script in job templates When gitlab prepares a job to run, it checks out the repository with a non-root user, and spawns a container that runs as root, with some UID mapping that makes the files be owned by root in the container. However, our pipelines run as a nont-root user. Commit bde165f7ad (.gitlab-ci.yml: update Docker image to use) updated the docker image that is used to run in our pipelines. That new image includes a git version that is stricter about the ownership of the git tree it is acting in: git aborts in error when the user running it does not own the repository. We use `git ls-tree` quite a lot in our check-{flake8,package,symbols} rules, so they all fail (in various ways). To fix this, we either need to fix the ownership or tell git to ignore the situation. In either case, we'll need to run a scriptlet before all our jobs. Gitlab-ci allows to provide a global before_script, that is inherited by all jobs. However, some of our jobs already declare a before_script, and that would shadow the global before_script. There is no technical reason to do our before_script separately from the actual script, so we move the code from the before_scripts to the corresponding scripts. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2023-02-07 22:33:11 +01:00
- OUTPUT_DIR=${CI_JOB_NAME}
utils/test-pkg: add gitlab-ci support The gitlab-ci support in test-pkg allows to parallelize the test-pkg work into several gitlab jobs. It's much faster than local serialized testing. To trigger this, a developer will have to add, in the latest commit of their branch, a token on its own line, followed by a configuration fragment, e.g.: test-pkg config: SOME_OPTION=y # OTHER_OPTION is not set SOME_VARIABLE="some value" This configuration fragment is used as input to test-pkg. To be able to generate one job per test to run, we need the list of tests in the parent pipeline, and the individual .config files (one per test) in the child pipeline. We use the newly-introduced --prepare-only mode to test-pkg, and collect all the generated .config files as artefacts; those are inherited in the child pipeline via the "needs::pipeline" and "needs::job" directives. This is a bit tricky, and is best described by the Gitlab-CI documentation [0]. We also list those .config files to generate the actual list of jobs to run in the child pipeline. Notes: - if the user provides an empty fragment, this is considered an error: indeed, without a fragment (and the package name), there is no way to know what to test; - if that fragment yields an empty list of tests, then there is nothing to test either, so that is also considered an error. [0] https://docs.gitlab.com/ee/ci/yaml/README.html#artifact-downloads-to-child-pipelines Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [yann.morin.1998@free.fr: - split the change to test-pkg to its own patch - generate the actual yml snippet in support/scripts/generate-gitlab-ci-yml, listing the .config files created by test-pkg - some code-style-candies... ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-08-21 15:46:46 +02:00
- echo "Configure Buildroot for ${OUTPUT_DIR}"
- make O=${OUTPUT_DIR} syncconfig
- make O=${OUTPUT_DIR} savedefconfig
- echo 'Build buildroot'
- *run_make
needs:
- pipeline: $PARENT_PIPELINE_ID
job: generate-gitlab-ci-yml
retry:
max: 2
when:
- runner_system_failure
- stuck_or_timeout_failure
utils/test-pkg: add gitlab-ci support The gitlab-ci support in test-pkg allows to parallelize the test-pkg work into several gitlab jobs. It's much faster than local serialized testing. To trigger this, a developer will have to add, in the latest commit of their branch, a token on its own line, followed by a configuration fragment, e.g.: test-pkg config: SOME_OPTION=y # OTHER_OPTION is not set SOME_VARIABLE="some value" This configuration fragment is used as input to test-pkg. To be able to generate one job per test to run, we need the list of tests in the parent pipeline, and the individual .config files (one per test) in the child pipeline. We use the newly-introduced --prepare-only mode to test-pkg, and collect all the generated .config files as artefacts; those are inherited in the child pipeline via the "needs::pipeline" and "needs::job" directives. This is a bit tricky, and is best described by the Gitlab-CI documentation [0]. We also list those .config files to generate the actual list of jobs to run in the child pipeline. Notes: - if the user provides an empty fragment, this is considered an error: indeed, without a fragment (and the package name), there is no way to know what to test; - if that fragment yields an empty list of tests, then there is nothing to test either, so that is also considered an error. [0] https://docs.gitlab.com/ee/ci/yaml/README.html#artifact-downloads-to-child-pipelines Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [yann.morin.1998@free.fr: - split the change to test-pkg to its own patch - generate the actual yml snippet in support/scripts/generate-gitlab-ci-yml, listing the .config files created by test-pkg - some code-style-candies... ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-08-21 15:46:46 +02:00
artifacts:
when: always
expire_in: 2 weeks
paths:
- build.log
- br-test-pkg/*/.config
- br-test-pkg/*/defconfig
- br-test-pkg/*/build/build-time.log
- br-test-pkg/*/build/packages-file-list*.txt