In T171342#3461960, @Dzahn wrote:

The other deployers would still have to decrypt the encrypted files to actually see content though, so it's not really sharing secrets with them unless we don't trust GPG by itself.

In T129139#3451681, @fgiunchedi wrote:

Completed

I think all these can be removed

@EBernhardson thank you for your investigation on this task! Sorry to send you so far down the rabbit hole, but I'm glad you came back with the rabbit :) This is a very satisfying explanation.

In T170648#3438280, @EBernhardson wrote:

While possible, I doubt the cirrus error is related to the train rollout. We have an ongoing intermittent issue related to elasticsearch with T168816 and more generally T169498.

wfm

Alerts and errors stopped when I rolled back to 1.30.0-wmf.7 so this seems to be caused by 1.30.0-wmf.9. Adding as blocker, raising priority.

Removing as train blocker: old log message in a new channel.

In T170596#3437768, @aaron wrote:

I don't see much noise from the logs about refreshLinks at https://logstash.wikimedia.org/goto/a029053d21a195163e68acc0a23e760e.

Removed as train blocker, seems to have been happening pre 1.30.0-wmf.9, sorry for the noise

Removed as train blocker, seems to have been happening pre 1.30.0-wmf.9, sorry for the noise

UBN since I added as a train blocker.

UBN since I added as a train blocker.

UBN since I added as a train blocker.

Seems like we've tested all we can test without actually calling the .write() method anywhere, lgtm!

rolled group0 forward and error has subsided.

UBN -- added as train blocker

+MediaWiki-extensions-TemplateSandbox since that's the line line that seems problematic in CommonSettings.php

The extra noise here was caused by T166348: Scribunto_LuaSandboxInterpreter::callFunction: LuaSandboxFunction::call returned false the root cause of which seems to be the luasandbox hhvm-module. While that is being fixed, we unfortunately have a higher than normal error rate. Scap appears to have been doing the correct thing here since this error rate is unacceptable — releng has made noise about this error potentially causing issues during the last train — however, this error appears unrelated to any specific code deployment over the past several weeks. See the linked task for full discussion.

Idiomatic getter

Few things I found from futzing on tin.

rethought this in D705

Now that D654 is landed all of the sync-* commands should always touch InitialiseSettings.php. It seems that we don't worry so much about T103886 this should be the correct behavior. This will roll with scap 3.6.0-1

In D654#13833, @demon wrote:

Per pretty extensive IRC discussions, we're reasonably confident that T103886 is no longer an issue. That, coupled with the fact that this option is routinely underused means we're probably safe in dropping this option. Suggest accepting :)

In T153270#3389414, @Legoktm wrote:

Where did this happen?

Rebase

In T166348#3382705, @Anomie wrote:

Looking at the logged data, it appears that there's some sort of a false positive in the luasandbox extension's recursion detection. I'm seeing it report the error when passing something as simple as [ "lang" => "ru" ].

I don't see any reason why it would false-positive though, unless it's possible for something to somehow throw an exception and exit from the middle of luasandbox_push_hashtable so it misses removing the entry from protectionSet, then later it happens to use the same pointer address for a different HashTable and hits the false-positive. Or unless IMPLEMENT_THREAD_LOCAL doesn't actually work.

I think the tl;dr is that scap tasks run from tin that do not run the promote stage should not change the DEPLOY_HEAD.

Change import style to jive with @dduvall 's suggestion

In T131949#3376851, @leila wrote:

In T131949#3371914, @schana wrote:

In T131949#3371909, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2017-06-22T19:31:55Z] <thcipriani@tin> Finished scap: SWAT: [[gerrit:360889|Translation updates for QuickSurveys]] T131949 (duration: 22m 10s)

This updated the translations for the survey buttons for (ar, hi, hu, ja, nl, ro)

It seems this didn't fix the issue. Users in rowiki are reporting that they still see the two buttons in English. I just tested the Arabic version and the issue persists there as well.