mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2025-12-20 07:20:10 +01:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
a66e227748
What we need is a way to tell GitLab "queue `build-only` jobs after `build-for-tests` jobs have started", to make sure that `build-only` jobs don't start before `build-for-tests` jobs and thus delays test jobs and the overall pipeline. The best I had found was "queue `build-only` jobs after *all* the `build-for-tests` jobs have finished", but this introduces a larger delay than we want, and causes `build-only` jobs to often be the last ones to finish in a pipeline, after test jobs that respect the 15min runtime limit. Instead, we can tell GitLab "queue `build-only` jobs after the `build-for-tests` jobs have been queued for X minutes", which is closer to what we want, and in particular this ensures the correct order of *starting* jobs as long as the CI is not overwhelmed and doesn't manage to actually start a queued `build-for-tests` job within 5min, in which case I'd argue we don't care about job order anymore because we have bigger problems anyway and likely everything's going to timeout. This also gets rid of the hard-to-maintain `.build-for-tests-jobs` list of `needs:`, which also needed to be manually merged in half the jobs. The trade-off is that we need to make a (shallow) copy of the `.container+build-rules` list, that replaces all the `when: on_success` with `when: delayed` + `start_in: 5 minutes`. This means that we'll need to make sure the two lists of conditions remain identical, but this seems more manageable; nevertheless, I added a comment to remind us. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33564> |
||
|---|---|---|
| .ci-farms | ||
| .ci-farms-disabled | ||
| .github/workflows | ||
| .gitlab | ||
| .gitlab-ci | ||
| .marge/hooks | ||
| android | ||
| bin | ||
| build-support | ||
| docs | ||
| include | ||
| licenses | ||
| src | ||
| subprojects | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .clang-format-include | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .graphqlrc.yml | ||
| .mailmap | ||
| .mr-label-maker.yml | ||
| .shellcheckrc | ||
| CODEOWNERS | ||
| meson.build | ||
| meson.options | ||
| README.rst | ||
| rustfmt.toml | ||
| VERSION | ||
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://docs.mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://docs.mesa3d.org/meson.html>`_): .. code-block:: sh $ meson setup build $ ninja -C build/ $ sudo ninja -C build/ install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `OFTC's #dri-devel <irc://irc.oftc.net/dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://docs.mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://docs.mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.