[08:10:10] 10GitLab (Administration, Settings & Policy), 10Release-Engineering-Team (Next), 10User-brennen: Establish a routine GitLab deployment / update window - https://phabricator.wikimedia.org/T287117 (10Jelto) We discussed in last ITC meeting that a dedicated GitLab update and maintenance window is not needed now... [08:10:46] 10GitLab (Infrastructure), 10Data-Persistence-Backup, 10serviceops, 10Patch-For-Review, 10User-brennen: Backups for GitLab - https://phabricator.wikimedia.org/T274463 (10Jelto) >>! In T274463#7835100, @jcrespo wrote: > [...] > BTW, restores directly to a different host are possible, although a bit cumber... [08:19:56] 10GitLab (CI & Job Runners), 10serviceops: upgrade gitlab-runners to bullseye - https://phabricator.wikimedia.org/T297659 (10Jelto) >>! In T297659#7862187, @Dzahn wrote: > @Jelto All the (non-protected) prod runners are upgraded. Now I was just wondering about the 2 protected runners. They are paused. Should... [08:20:10] 10GitLab (CI & Job Runners), 10serviceops: upgrade gitlab-runners to bullseye - https://phabricator.wikimedia.org/T297659 (10Jelto) [08:31:57] 10GitLab (CI & Job Runners), 10Security-Team, 10serviceops, 10Patch-For-Review, and 2 others: Setup GitLab Runner in trusted environment - https://phabricator.wikimedia.org/T295481 (10Jelto) [09:03:22] 10GitLab (CI & Job Runners), 10Release-Engineering-Team (Doing): Add concurrent parameter to profile::gitlab::runner - https://phabricator.wikimedia.org/T293833 (10Jelto) 05Open→03Resolved This has been implemented in https://gerrit.wikimedia.org/r/732093, I'm closing this task. [14:51:59] 10GitLab (Administration, Settings & Policy), 10Release-Engineering-Team (Next), 10User-brennen: Establish a routine GitLab deployment / update window - https://phabricator.wikimedia.org/T287117 (10brennen) 05Open→03Declined Makes sense. We can revisit this in future if needed. [15:25:43] hello! i've been doing some work with includable reusable gitlab templates, and they are great. However, I'm encountering a little weirdness with merge request pipelines that I'm sure is just me missing something. [15:26:09] When I make a commit to a branch that is part of a merge request [15:26:33] the test jobs only seem to run on the commit pipeline, but not the 'merge request pipeline'. That is, there are 2 pipelines that are created as a result of my commit. [15:26:51] Example: [15:26:56] commit pipeline: https://gitlab.wikimedia.org/repos/data-engineering/example-job-project/-/pipelines/3341 [15:27:05] merge request pipeline: https://gitlab.wikimedia.org/repos/data-engineering/example-job-project/-/pipelines/3342 [15:27:58] it doesn't matter too much, but I would hope that the Pipelines tab on the MR UI would link to pipelines that would run tests. https://gitlab.wikimedia.org/repos/data-engineering/example-job-project/-/merge_requests/33/pipelines [15:28:44] I have seen tests run in MR pipelines before, so I'm wondering if somehow my work with including gitlab templates from a remote repo has caused some weird CI/CD settings changes I'm not aware of [15:28:49] brennen: maybe ^ ? [15:57:12] looking. [16:07:08] (ty) [16:46:10] ottomata: having not gotten super deep into this, i wonder if there are rules in the included jobs governing this? [16:46:26] was just skimming git@gitlab.wikimedia.org:repos/data-engineering/example-job-project.git [16:46:30] er, sorry, wrong paste [16:46:38] https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html [16:46:52] https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html#use-rules-to-add-jobs [16:47:52] in workflow_utils/gitlab_ci_templates/conda-dist.yml i notice a `rules` that checks $CI_COMMIT_TAG... [17:40:49] hm yes some do use rules, but it seems even if I comment out the inclusion of those templates, my dummy test job doesn't run. Also, those templates only add jobs to the deploy stage, which I assumed wouldn't affect the test stage jobs? [17:40:53] lemme try tho [17:47:04] brennen: interesting, indeed, if I add e.g. rules: - when: always, the test runs. hm. [18:14:26] The note "[Merge request pipelines] Do not run by default. The jobs in the CI/CD configuration file must be configured to run in merge request pipelines." is kind of hidden on https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html [18:20:53] Interesting. I'm pretty sure that I've seen pipelines associated merge requests without having to do this though. example: https://gitlab.wikimedia.org/repos/data-engineering/workflow_utils/-/merge_requests/16/diffs#587d266bb27a4dc3022bbed44dfa19849df3044c [18:22:43] oh hm interesting. [18:23:21] I think those are not 'Merge Request Pipelines', just the the commit pipeline is being correctly associated with the MR. [18:23:52] which is really all i want: i want to see the pipelines that run because of commits on a MR branch in the Pipelines tab of the MR. [18:24:25] In that example they do. But in my current attempts they don't (without settting e.g. rules: when: always)