i915-infra issueshttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues2019-11-14T07:36:53Zhttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/72Tag idle runs too2019-11-14T07:36:53ZArkadiusz HilerTag idle runs too(reported by @l4kshmi)
We have [repositories with tags for kernel and IGT](https://intel-gfx-ci.01.org/#repositories-with-ci-tags) and we already tag most of our post-merge and pre-merge runs - `CI_DRM_`, `Patchwork_`, `IGTPW_`, `IGT_`....(reported by @l4kshmi)
We have [repositories with tags for kernel and IGT](https://intel-gfx-ci.01.org/#repositories-with-ci-tags) and we already tag most of our post-merge and pre-merge runs - `CI_DRM_`, `Patchwork_`, `IGTPW_`, `IGT_`.
One missing bit are [idleruns](https://intel-gfx-ci.01.org/#idle-runs). We should push tags for them too!https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/53Add link to results.json.bz22019-07-02T07:56:06ZArkadiusz HilerAdd link to results.json.bz2https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_319/fi-cml-u2/igt@runner@aborted.html
Those pages link to the correct boot/dmesg/etc. logs but raw results.json.bz2 comes handy, especially for checking on unusual results.
The file is al...https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_319/fi-cml-u2/igt@runner@aborted.html
Those pages link to the correct boot/dmesg/etc. logs but raw results.json.bz2 comes handy, especially for checking on unusual results.
The file is already uploaded, so let's add link to the template that is used to render those pages.https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/43vis: Figure out good UX for caching the test filter2020-02-06T17:22:32ZArkadiusz Hilervis: Figure out good UX for caching the test filterThe new vis (!33) comes with a text field in the navbar that is used for filtering grids on test names and by default cached that.
The UX it presented though is too confusing (value stays there forever, no button to clear it, not easy ...The new vis (!33) comes with a text field in the navbar that is used for filtering grids on test names and by default cached that.
The UX it presented though is too confusing (value stays there forever, no button to clear it, not easy to spot), especially for people coming without the implementation knowledge so the caching got disabled as of b0980dc3.
TODO:
* [ ] Add a (x) to reset the value
* [ ] Make persistence optional (checkbox?)
* [ ] make filter more visible (either by putting red "filter" in the front or by blinking it?)https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/32vis: Make new tests more visible2020-02-06T09:33:27ZArkadiusz Hilervis: Make new tests more visibleCurrently, to find the new tests in the visualization you have to go to "shards all" view and then search in the page for new tests names.
With #11 we will already start using data from [cibuglog](/gfx-ci/cibuglog) for the visualization...Currently, to find the new tests in the visualization you have to go to "shards all" view and then search in the page for new tests names.
With #11 we will already start using data from [cibuglog](/gfx-ci/cibuglog) for the visualization of the results.
We can do similar thing with information about new tests (cibuglog already has logic for finding them, [example](https://lists.freedesktop.org/archives/igt-dev/2019-February/009605.html)).
With that included in the .json we could have the new tests on the combined views and/or we could highlight them somehow.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/26VKMS in the farm2019-02-07T09:11:12ZArkadiusz HilerVKMS in the farmThis is related to Targeted Testing #25.
We need to figure out what's the best way to deploy VKMS, probably with its own dedicated test list.
VM? Bare metal with i915 disabled?
@adrinael has hands on experience with this, so assignin...This is related to Targeted Testing #25.
We need to figure out what's the best way to deploy VKMS, probably with its own dedicated test list.
VM? Bare metal with i915 disabled?
@adrinael has hands on experience with this, so assigning for now to him.Petri LatvalaPetri Latvalahttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/19vis: collapse hosts that do not have anything interesting to display2018-12-19T15:04:38ZArkadiusz Hilervis: collapse hosts that do not have anything interesting to displayshowing information about what has been collapsed so that we don't confuse people is the hardest partshowing information about what has been collapsed so that we don't confuse people is the hardest parthttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/11Showing Bug id for all ci test failures in CI results visualization page.2019-05-14T15:21:21ZLAKSHMINARAYANA VUDUMShowing Bug id for all ci test failures in CI results visualization page.Navigate to any CI results page (BAT/SHARDS/DRMTIP).
Move cursor to any failure (fail/dmesg-warn/warn/incomplete/crash/dmesg-fail)
If a bug exists for this failure, show the bug id.
This way anyone can find the bug id for any test fail...Navigate to any CI results page (BAT/SHARDS/DRMTIP).
Move cursor to any failure (fail/dmesg-warn/warn/incomplete/crash/dmesg-fail)
If a bug exists for this failure, show the bug id.
This way anyone can find the bug id for any test failure if a bug exists already.Petri LatvalaPetri Latvalahttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/3Collect the hardware information before each CI run2020-05-05T07:41:31ZMartin RoukalaCollect the hardware information before each CI runThe hardware information should be collected for all machines, timestamped and should also contain the runconfig it was collected on.
This will make it easier to know when they were collected and will allow us to update the website fast...The hardware information should be collected for all machines, timestamped and should also contain the runconfig it was collected on.
This will make it easier to know when they were collected and will allow us to update the website faster and more consistently.