The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

Thank you!

Possibly linked with T380434. @Reedy What do you think?

g4.cores4.ram8.disk20 is working out well.

In T377883#10313775, @colewhite wrote:

In T377883#10313476, @dancy wrote:

If it does, that would be useful to us as we work on transitioning to Prometheus style metrics (which support labels in a similar way to Graphite tags).

We use statsite as the metrics entry point. I would guess it doesn't from a quick look at the docs and bug tracker.

@lmata @colewhite Does the existing statsd listener accept tagged datapoints like so?

metric_name;tag1=value1;tag2=value2

If it does, that would be useful to us as we work on transitioning to Prometheus style metrics (which support labels in a similar way to Graphite tags).

scap 4.123.0 has been deployed which should address this problem.

scap 4.123.0 has been deployed which should address the scap side of this problem.

Declaring this resolved.

I think using scap train makes it hard/impossible to do this. If you do use scap train to advance from (for example) group0 to group2, group1 will be promoted too.

In T347982#10261422, @CodeReviewBot wrote:

legoktm opened https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/507

update-interwiki-cache: Give some output on success

In T375659#10259623, @dancy wrote:

Train is blocked at group1 due to T378108.

In T378108#10259626, @Pppery wrote:

I don't think it will get any worse - FundraiserLandingPage only runs on DonateWiki which is group1.

Train is blocked at group1 due to T378108.

I made this a train blocker because I'm worried about the warning log rate when rolling to group2.

Could this be related to T378003?

I wonder if this is related to T377912 which also mentions \Wikimedia\Message\ScalarParam

@Esanders Is a cherry-pick of https://gerrit.wikimedia.org/r/1082472 to wmf/1.43.0-wmf.28 sufficient to unblock the train?

In T377860#10250810, @Lucas_Werkmeister_WMDE wrote:

Pretty sure this is the same as T373087, which should be fixed with this week’s train.

In T377672#10247106, @dancy wrote:

@Esanders Hello. I'm on train duty this wek and @Jdlrobson added this task as a train blocker. Can you ensure that the relevant fix is backported to the wmf/1.43.0-wmf.28 branch?

@Esanders Hello. I'm on train duty this wek and @Jdlrobson added this task as a train blocker. Can you ensure that the relevant fix is backported to the wmf/1.43.0-wmf.28 branch?

Fixed in scap 4.111.0, which I deployed today.

Fixed in scap 4.111.0, which I deployed today.

Congrats @hashar! You're a CI hero.

In T376932#10219246, @egardner wrote:

Hey @dancy – what do you think about showing only the last X number of jobs on the main page and then having a "view all jobs" link to a dedicated jobs/ page that lists all the jobs for all time? Both could use the Codex table component, but this might be a way to keep the main page ( the / route ) cleaner.

Here are screenshots of the current prototype:

Previously docker commands were only run by the mwbuilder user (via sudo) during image build. Now docker is executed by whoever is running scap. The users in the docker group are a subset of the users in the deployment group, which is why this error happened.

In T374880#10153611, @dancy wrote:

Considering this resolved after https://gerrit.wikimedia.org/r/1073286. However I do have some remaining suspicions about the rollback behavior should scap deploy fail. I don't get the impression that the checks run on rollback, so a rollback isn't really a rollback for phatality.

Deployed with scap 4.104.0

https://chromewebstore.google.com/detail/wikimediadebug/binmakecefompkjggiklgjenddjoifbb?hl=en-US&pli=1 is showing version 2.9.0 so I think that's done too.

The updated Firefox add-on is available at https://addons.mozilla.org/en-US/firefox/addon/wikimedia-debug-header/.
The update has been uploaded to Chrome Web Store and is pending processing.

Considering this resolved after https://gerrit.wikimedia.org/r/1073286. However I do have some remaining suspicions about the rollback behavior should scap deploy fail. I don't get the impression that the checks run on rollback, so a rollback isn't really a rollback for phatality.

I filed https://github.com/moby/buildkit/issues/5329 about the build problem.

In T374478#10139303, @brennen wrote:

error: failed to solve: failed to load cache key: failed to fetch remote https://github.com/containers/dnsname.git: git stderr:
fatal: unable to access 'https://github.com/containers/dnsname.git/': Failed to connect to github.com port 443 after 129806 ms: Couldn't connect to server
: exit status 128

Unclear whether this is just a transient failure or if something else is up.

https://gerrit.wikimedia.org/r/1071027 failed on testservers when accessing https://commons.wikimedia.org/wiki/Campaign:Photographier_le_patrimoine_vivant_en_France_2024:

The target for today was to reach group1, but we only made it to group0 this afternoon. Error logs look ok right now but I want to let it marinate for a while. @hashar If you can, please roll the train to group1 during the next window. Thanks in advance!

https://gerrit.wikimedia.org/r/1070657 has been fully deployed.

Rolled the train back due to T374046

Possibly related to T373920 ?