i915-infra issueshttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues2019-12-04T11:23:43Zhttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/77Bot for ensuring the we use only one of the labels within the scope2019-12-04T11:23:43ZArkadiusz HilerBot for ensuring the we use only one of the labels within the scope[GitLab Premium has a feature called scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels-premium), which allows only one label from a given scope to be set on an issue.
Scopes are prefixed with `scope_name:...[GitLab Premium has a feature called scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels-premium), which allows only one label from a given scope to be set on an issue.
Scopes are prefixed with `scope_name::`.
With bug migration from bugzilla to GitLab we followed this notation whenever applicable hoping that this feature would eventually end up in community edition.
In the meantime we can create **a bot** that periodically queries issues **looking for such conflicts** and then resolves them by **dropping all but the most recently applied label** from a given scope.https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/39i915 infra reimagined2019-05-03T11:49:30ZArkadiusz Hileri915 infra reimagined**Cc:** @adrinael @mupuf @tsa @danvet @emersion
## Why?
Current infra is the initial PoC that evolved over time amalgamating quite a bit of cruft. It works, it proves a point, but
it is time to start defining interfaces, codify some b...**Cc:** @adrinael @mupuf @tsa @danvet @emersion
## Why?
Current infra is the initial PoC that evolved over time amalgamating quite a bit of cruft. It works, it proves a point, but
it is time to start defining interfaces, codify some behaviors and redo the ugly parts.
## How?
By defining interfaces and boundaries between components (most of which that we already have in some form or another). When we have those we can start molding current CI blocks to follow them, and replace anything that needs replacing along the way.
## Key Concepts
**Trigger** - an external trigger (e.g. new series in patchwork, new commit in SCM) that results in a **job** being **scheduled**
**Job** - (meta-)data that describe testing to be done e.g.: git tree, patches to apply, runtype (fast-feedback, shards, etc. Passed through all the defined interfaces, with new data appended (link to built assets, results, etc).
**Scheduler** - does the job management prior to **executing** them, basing on the priorities, types, etc. May have multiple queues internally and drive multiple executors concurrently.
**Executor** - component that manages (a) pool(s) of machines, takes care of their life-cycle and governs execution. Some examples: deploying new kernels, deploying test assets (piglit/IGT), executing tests, collecting results, keeping track of machine life-cycle and doing automated recovery if necessary. Other example: something building the assets out of our source.
**Reporter** - When a Job exists **execution** stage the results need to be processed/published (e.g. by gfx-ci/cibuglog>) This is the stage/component that handles that. Reporting may also act as an **trigger** (e.g. successful BAT triggers sharded run).
```mermaid
graph LR
TP[Trigger Patchwork] -- JOB --> S[Scheduler];
TS[Trigger SCM] -- JOB --> S;
S --> E1[Executor 1];
S --> E2[Executor ...];
S --> E3[Build Executor];
E1 --> R[Reporting]
E2 --> R;
E3 --> R;
R -- JOB --> S;
```
## Technology Choices
**Containers** - both as build environment and deployment assets for user space for consistency and reproducibility. On the tests systems we want to run them in chroot-like manner to avoid any possible isolation from HW.
## How To Progress
1. Select a boundary
2. Define the interface
3. Start working on components on both sides (adjust existing ones if possible) to follow the interface
4. Rinse and repeat
## FAQ
**Q:** Why OCI containers and not Puppet/Ansible/PXE/..?<br/>
**A:** https://jvns.ca/blog/2016/10/26/running-container-without-docker/https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/30Request to add the ability to install packages at test build time to CI platf...2019-02-21T12:41:13ZStuart SummersRequest to add the ability to install packages at test build time to CI platforms.IGT currently has Docker files for fedora and debian distros. It would be great if CI had the ability to extract these packages (or run within Docker itself) to install required dependencies as part of patch verification. I'd like to req...IGT currently has Docker files for fedora and debian distros. It would be great if CI had the ability to extract these packages (or run within Docker itself) to install required dependencies as part of patch verification. I'd like to request we add the infrastructure to do that. Thanks!https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/25Targeted Testing Farm2019-02-07T09:11:13ZArkadiusz HilerTargeted Testing FarmCc: @adrinael @tsa @mupuf @danvet
## The problem
Some of the features require dedicated peripherals for testing (e.g. HDCP enabled monitors, Chamelium, PSR panels). Such configurations do not fit well with the current BAT/SHARDS divisi...Cc: @adrinael @tsa @mupuf @danvet
## The problem
Some of the features require dedicated peripherals for testing (e.g. HDCP enabled monitors, Chamelium, PSR panels). Such configurations do not fit well with the current BAT/SHARDS division:
1) adding 8 exact same setups with all the peripherals is hard/uneconomical
2) results readability would suffer if we would introduce more skips or try to bunch up different test sets on a single view
## Proposed solution:
Dedicated machines with dedicated testlists, under working-title "Targeted Testing".
**Execution side:** machines would be tagged with "TARGETED" and each machine would have a testlist assigned (e.g. `TESTLIST=tests/intel-ci/chamelium.testlist`). Execution would be scheduled along shards - they should take no more time than that - 40 min is plenty.
**Visualization side:** Separate results view type called "targeted testing" in the dropdown along the "combined", "shards", "BAT". It will have testlist-based sections (just like we have them in combined view), i.e. we would get all results for `tests/intel-ci/hdcp.testlist` first, then another section for `tests/intel-ci/chamelium.testlist`, etc.
**Report side:** We can either introduce a new e-mail, or figure out how to communicate the results, in a way that is not confusing, in the shards report.
Any ideas? Concerns? Improvements?https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/7Renaming the runs2019-02-20T13:03:46ZMartin RoukalaRenaming the runsThe KASAN and DRMTIP runs are not listed in the list of views in https://intel-gfx-ci.01.org/tree/drm-tip/
@ivyl was suggesting that we should fix the name first, which I do not disagree. How about calling them "CI-Full Idle" and "CI-Fu...The KASAN and DRMTIP runs are not listed in the list of views in https://intel-gfx-ci.01.org/tree/drm-tip/
@ivyl was suggesting that we should fix the name first, which I do not disagree. How about calling them "CI-Full Idle" and "CI-Full Idle - KASAN"?
Any opinion @tsa?Arkadiusz HilerArkadiusz Hiler