Resolved

@Paladox less than a week until end of goal period - do we have an update on this?

This task has taken a back foot, over other work which has higher priority currently such as T8469 T8350

https://github.com/miraheze/mediawiki/blob/REL1_37/.github/workflows/label.yml
confirmed to work on https://github.com/miraheze/mediawiki/pull/4440

We can also add labels with:

pull_number=$(jq --raw-output .pull_request.number "$GITHUB_EVENT_PATH")
curl \
  -X POST \
  -H "Accept: application/vnd.github.v3+json" \
  -H 'Authorization: token ${{ secrets.GITHUB_TOKEN }}' \
  https://api.github.com/repos/${GITHUB_REPOSITORY}/issues/$pull_number/labels \
  -d '{"labels":["build"]}'

And we can parse the list of files with:

git -c color.diff=false diff --submodule=diff $submodule | sed -n -e s/^diff\ --git\ a\\///p

I have this to parse the dependabot branches into which submodule to check against, and properly get the full diff of them. I still don't know how to use this, convert it into a list of only files changed (as --name-only won't work with git diff for submodules). If we can convert it to a simple list somehow, then we still need to figure out how to use that list, add some regex checks on it, and add a label to it, to make it clearer what changes are made.

In T7052#169451, @RhinosF1 wrote:

https://github.com/srvaroa/labeler/issues/35 was filed by you so hopefully this might get a better response

https://github.com/srvaroa/labeler/issues/35 was filed by you so hopefully this might get a better response

And I know nothing about the "go" Language so I can't attempt to fork these labeler actions to fix them to work with submodules.

https://github.com/miraheze/mediawiki/pull/4385 is the new one by the way. It at least does stuff, but doesn't work for submodules still.

In T7052#169447, @Universal_Omega wrote:

In T7052#169444, @RhinosF1 wrote:

What do you mean for other stuff?

We can definitely pull data in git submodules as we run tests on them.

The new one works for .github/test to label "build" whereas the original didn't.

As for tests, what tests do we run on them?

Actually not in our org at the moment but I'm pretty sure bots has examples. We did have it while we were attempting to add them to the mediawiki repo though.

In T7052#169444, @RhinosF1 wrote:

What do you mean for other stuff?

We can definitely pull data in git submodules as we run tests on them.

Community forum and issue on repo got nothing

As suggested to Reception given this is maintained by github staff, we could email support and hope that gets us better luck.

What do you mean for other stuff?

As far as I can tell now no GitHub action will work to get submodules files changed like the labeler action method was intended for. My new one works for other stuff, whereas before nothing worked, but submodules are still not working. I honestly have no idea how to continue here seeing as how the current actions are written in go which I have absolutely no knowledge or understanding of.

In T7052#169436, @John wrote:

@Universal_Omega Do you think this can be done before December 31st?

@Universal_Omega Do you think this can be done before December 31st?

In T7052#169412, @John wrote:

Can we have an update on this goal please?

The solution we currently have is a bit buggy

Can we also have a plan for realistic completion or significant progress before this goal period is update December 31st please?

@Universal_Omega said he'd look at a fix and forking the actions/labeller tool soon

Can we have an update on this goal please?

I am going to start progress on this task, firstly by cleaning up how we define all of this in puppet. I'll introduce simply logging stanzas that we can define over and over again for each log file, that handles all of the syslog-ng logic + logrotate configuration for the new system.

New server list for checking the above plan against:

Plan for resolving this task:

• All services will have their logs ingested into Graylog, this isn't negotiable.
• Where logs are ingested, we will maintain 24-48 hours of *local* logs on the server. This will be supported by log rotation.

This is now resolved.

db13:

• Time taken: 2 hours and 20 minutes
• Size: 33G

https://github.com/miraheze/puppet/compare/6d6dcbc15b0e...139bf730eb26 automates this for daily, so we should have a live accessible copy for a 24 hour RPO - and bacula will store backups for a longer period of time (TBD).

The backup ran for 14 hours before I killed it as it caused T8163.

Currently doing the above command but over an NFS mount to dbbackup1 which is in the US. This will take significantly longer - that is the main thing I am interested in right now.

mydumper -G -E -R -m -v 3 -t 2 -c -x "^(?!([0-9a-z]+wiki.(objectcache|querycache|querycachetwo|recentchanges|searchindex)))" -L "/home/johnflewis/$(date +"%Y%m%d%H%M%S").log" --trx-consistency-only

On db12:

• Time taken: 103 minutes (1 hour and 43 minutes)
• Size: 30G

Trying to optimise the dump by reducing amount of data carried over (because not everything in MediaWiki is irreplaceable!)

T7740 is likely to be influenced by work done on this task.

De-assigned per lack of progress.

@Southparkfan Any updates on this task? If there isn't an update provided in a week, I'll reassign the task to ensure it gets completed.

In T5044#156437, @John wrote:

@Paladox has raised concerns with centralised-only logging. We should explore these concerns before pushing for things like nginx access logs as these are critical for debugging some traffic influx/DoS attacks.

I agree with that. At least for some logs it's definitely useful to have logs stored locally in case something goes wrong and the logs don't get transmitted to graylog.

@Paladox has raised concerns with centralised-only logging. We should explore these concerns before pushing for things like nginx access logs as these are critical for debugging some traffic influx/DoS attacks.

Updates since last one on June 1st?

This has now been deployed.

Raising priority to high per conversation with Owen and request that this is done ASAP. I will try to test and deploy this today.

In T5412#154985, @Universal_Omega wrote:

This has now been deployed.

This has now been deployed.

Currently blocked on community consensus.

https://github.com/miraheze/ManageWiki/pull/290

I guess this wasn't moved over to the next goal period, so doing that.

I drafted a bit of JS for this, using the oojs dialogs. This should be fairly good to do, with a "review" button, next to the save button, so it does not annoy users if they don't want to review them.

Moving over to new goal period. Feel free to remove if it isn't wanted to be moved over.

Moving over to new goal period. Feel free to remove if it isn't wanted to be moved over.

+previous goal period as was removed after period finished

I could look into taking this over from @Paladox. Is there anything not on this task that I should be aware of if I do?

This went live after T7117: Upgrade to MediaWiki 1.36.0 was done.

The latency between db and dbbackup causes the slowness in the dump process. Moving the dbbackup VM to NL should improve the performance, but NL is much closer to UK than the US is. A disaster impacting both UK and NL is not very likely, but still...

https://github.com/miraheze/IncidentReporting/pull/22 should complete this.

Removing the Extensions project since this is tagged with RemovePII now and we don't usually tag Extensions when tagging an additional Miraheze extension project.