Searched refs:CI (Results 1 – 21 of 21) sorted by relevance
/qemu/.gitlab-ci.d/cirrus/ |
H A D | README.rst | 1 Cirrus CI integration 4 GitLab CI shared runners only provide a docker environment running on Linux. 8 To work around this limitation, we take advantage of `Cirrus CI`_'s free 10 CI jobs from GitLab CI jobs so that Cirrus CI job output is integrated into 11 the main GitLab CI pipeline dashboard. 20 * enable the `Cirrus CI GitHub app`_ for your GitHub account; 25 * grab an API token from the `Cirrus CI settings`_ page; 29 Cirrus CI knows about your project by navigating to: 41 of it can impersonate you as far as Cirrus CI is concerned. 52 .. _Cirrus CI settings: https://cirrus-ci.com/settings/profile/ [all …]
|
/qemu/docs/devel/ |
H A D | ci-jobs.rst.inc | 3 Custom CI/CD variables 6 QEMU CI pipelines can be tuned by setting some CI environment variables. 8 Set variable globally in the user's CI namespace 11 Variables can be set globally in the user's CI namespace setting. 37 CI configurations. For example define an alias for triggering CI: 92 CI configuration file. 97 The job makes use of Cirrus CI infrastructure, requiring the 104 by default due to need to conserve limited CI resources. It is 105 available to be started manually by the contributor in the CI 113 CI pipeline. [all …]
|
H A D | ci.rst | 4 CI chapter 7 Most of QEMU's CI is run on GitLab's infrastructure although a number 8 of other CI services are used for specialised purposes. The most up to 10 `project wiki testing page <https://wiki.qemu.org/Testing/CI>`_.
|
H A D | ci-runners.rst.inc | 4 Besides the jobs run under the various CI systems listed before, there 6 These use the same GitLab CI's service/framework already used for all 7 other GitLab based CI jobs, but rely on additional systems, not the 10 The architecture of GitLab's CI service allows different machines to 16 The GitLab CI jobs definition for the custom runners are located under:: 21 currently deployed in the QEMU GitLab CI and their maintainers, please 73 * CI/CD, then 92 * CI/CD, then
|
H A D | ci-definitions.rst.inc | 84 Continuous Integration (CI) 87 Continuous integration (CI) requires the builds of the entire application and 92 Keynotes about continuous integration (CI) [9]_:
|
H A D | testing.rst | 313 much memory and disk space (since CI pipelines tend to fail otherwise). 447 available in the CI build environments. 473 * CI pipeline will run to validate that the changes to ``mappings.yml`` 485 `CI <https://www.qemu.org/docs/master/devel/ci.html>`__ documentation 486 page on how to trigger gitlab CI pipelines on your change. 491 `CI <https://www.qemu.org/docs/master/devel/ci.html>`__ documentation 492 page on how to trigger gitlab CI pipelines on your change. 511 There are limited CI compute resources available to QEMU, so the 540 * CI pipeline will run to validate that the changes to ``mappings.yml`` 1388 This includes tests that don't run reliably on GitLab's CI which [all …]
|
H A D | submitting-a-patch.rst | 204 testing pipeline on GitLab when a branch is pushed. See the :ref:`CI
|
/qemu/ |
H A D | .gitlab-ci.yml | 2 # This is the GitLab CI configuration file for the mainstream QEMU 10 # you need to set the location of your custom yml file at "custom CI/CD 11 # configuration path", on your GitLab CI namespace: 16 # QEMU CI jobs are based on templates. Some templates provide
|
/qemu/.gitlab-ci.d/ |
H A D | cirrus.yml | 1 # Jobs that we delegate to Cirrus CI because they require an operating 5 # The Cirrus CI configuration is generated by replacing target-specific 7 # when the GitLab CI job is defined, others are taken from a shell 11 # special care, because we can't just override it at the GitLab CI job 19 # as there's often a 5-10 minute delay before Cirrus CI
|
H A D | custom-runners.yml | 1 # The CI jobs defined here require GitLab runners installed and 3 # versions and architectures. This is in contrast to the other CI
|
H A D | base.yml | 8 # For purposes of CI rules, upstream is the gitlab.com/qemu-project 9 # namespace. When testing CI, it might be usefult to override this
|
H A D | crossbuilds.yml | 115 # allow_failure so as not to block CI.
|
H A D | buildtest.yml | 291 # but often the CI system is the only way to trigger the failures. 709 # GitLab publishes from any branch that triggers a CI pipeline
|
/qemu/tests/docker/dockerfiles/ |
H A D | debian-hexagon-cross.docker | 5 # needs to be able to build QEMU itself in CI we include its 29 # Install QEMU build deps for use in CI
|
/qemu/target/ppc/translate/ |
H A D | misc-impl.c.inc | 103 * - loads from CI memory. 104 * - stores to CI memory. 119 * The end result is that CI memory ordering requires TCG_MO_ALL
|
/qemu/python/tests/ |
H A D | minreqs.txt | 3 # by GitLab CI to ensure that our stated minimum versions in setup.cfg
|
/qemu/hw/audio/ |
H A D | cs4231a.c | 100 #define CI (1 << 5) macro 518 s->dregs[Alternate_Feature_Status] &= ~(PI | CI | TI); in cs_write()
|
/qemu/docs/system/devices/ |
H A D | canokey.rst | 46 Also since this is a virtual card, it can be easily used in CI for testing
|
/qemu/qga/ |
H A D | meson.build | 187 # the leak detector in build-oss-fuzz Gitlab CI test. we should re-enable
|
/qemu/docs/about/ |
H A D | deprecated.rst | 159 cross-compilation CI tests of the architecture. As we no longer have 160 CI coverage support may bitrot away before the deprecation process
|
H A D | removed-features.rst | 997 tripped up the CI testing and was suspected to be quite broken. For that
|