matmarex / patchdemo Goto Github PK

Is it possible to have a button to invert the currently selected extensions/skins to be enabled, or to set them all to disabled, rather than needing to click each manually? (Though it should probably require a skin be enabled so that it works)

You could potentially use the docker-compose environment in core (which defaults to SQLite as the DB backend) for some of this. You'd need to create docker-compose.override.yml files for each patch demo directory that specify ports: 8080 and then ask docker which port was assigned, so you can report that back to the user.

For example https://gerrit.wikimedia.org/r/#/q/576855 returns two results, one for change 576855 (the desired change) and one for https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/342948/ which has a commit hash starting with 576855.

It would probably just be better to use a git-review -d equivalent command to give the QA the same experience as the dev, and not require them to list all dependencies manually.

Also the git-review -d command is guaranteed to work, whereas a cherry-pick can fail if you don't have the correct dependencies, which leaves the wiki in a broken state.

A general solution to #19 proposes some security issues. However we could have a list of safe configs and types they can be set to, e.g. $wgContentLang = <string> should be relatively safe.

http://patchdemo.wmflabs.org/wikis/b06eb2e7b02e28684e8e30dbc36c0585/w/index.php/Main_Page?veaction=edit

Error contacting the Parsoid/RESTBase server (HTTP 500)

It would probably be better if it said something like:

This wiki was automatically generated by [https://github.com/MatmaRex/patchdemo patchdemo] at datetime and applies the following patches:

• https://gerrit.wikimedia.org/...
• ...

This wiki may be deleted in the near future so do not expect links to it to persist.

The main page is setup in Installer.php#createMainpage.

Currently phabracitor/gerrit.wikimedia.org is hard-coded in a few places. It should be a config setting (defaulting to Wikimedia).

This would allow demonstrations of features hidden behind feature flags, for example.

We don't want to let people add arbitrary PHP to local settings, so we'd probably need to do something JSON-based instead.

Using the notifications API we can tell the user when their wiki has been built. Building a wiki can take a few minutes during which you are likely to switch to another task.

https://www.mediawiki.org/wiki/Extension:CodeMirror

On live servers, there is a stylus button on the toolbar just left from "Advanced" in WTE2010:
https://www.mediawiki.org/w/index.php?title=2017_wikitext_editor&action=edit&useskin=timeless
to turn on syntax highlighting. It's missing here:
http://patchdemo.wmflabs.org/wikis/8aa1bf729181edce0a4d14d78d04ee3f/w/?useskin=timeless&action=edit

The button is in the hamburger menu dropdown in WTE2017 (VisualEditor's new wikitext editor).
Missing:
http://patchdemo.wmflabs.org/wikis/1e7905405c7e9513605490187cb54a43/w/?useskin=timeless&veaction=editsource

Looks like this is already partially solved problem from 92eb8f4 but if not, you could use Quibble with something like quibble --skip-install --skip-deps -c "echo Done!" to install specific versions used by a given patch / build. The docs for doing that are here

Some changes will only affect those with specific permissions; to test them, a privileged user is needed. I suggest a 'crat (has userrights) be created when a new test wiki is created, with a public password (can even be noted in the customized main page following #7)

Along the theme of cleaning up old wikis (#14):

We can show a reminder along the lines of "7 of your wikis were built from patches than have now been merged. You should consider deleting these to free up space."

Bad Request
Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.
Apache/2.4.38 (Debian) Server at patchdemo.visualeditor.eqiad.wmflabs Port 80

Happened on https://patchdemo.wmflabs.org/ after oauthing.
It turns out, session cookies have Path == '/' set.

I've managed to hoard a considerable stash, enough for a Christmas party, sent around with each request. If only we could eat them...

Can you limit the session cookies to the path of the individual wikis?

Currently it is assumed that you are installing in /var/www on an otherwise empty VM. You may want to install in /var/www/patchdemo, e.g. for local developement.

e.g. localhost/sites/md5/w/...

This will make maintenance of installed wikis easier, and we can also add that folder to .gitignore.

Link: https://github.com/MatmaRex/patchdemo#faq

Current message:
Any wiki created with this tool may be deleted at any time along with all the content on it, so you should not rely on them being available, or use them to store important information.

Append:
For more information please see our FAQ.

Between creating 2 wikis the I often have to re-authenticate.
I haven't measured exactly, it might have taken between 10min - 1 hour to set up one wiki and finish (verify) the patch for the next.
In any case it feels like I have to auth too often.
A month or a week or infinite would be good for me, but doing many times a day does not seem a practical use of time, nor a security advantage.

Can this be adjusted?

Use-case: for some changesets I've set up test users, a demo page. I demoed 4 patches from a chain, a small error in the first patch required a rebase of the whole chain and recreation of the 4 patches, setting up a user + main page on all 4 again. I expect I'll be doing this again and again. An option to update a former wiki would make this a snap.

Any "Bug: Txxxxx" comments in commit messages should be aggregated and linked to on the Main_Page for extra context.

If someone visits index.php while a wiki is building, the metadata for a partially built wiki may get cached. We could not cache broken wikis, but that would mean we try to evaluate metadata for actually broken wikis on every view.

I've created this demo: 0516ae808872d38b5bdf96e2559feeb1 patch: 578568,10
And another demo was created additionally: 24b6fd1f6a50fc53846f92f943ce79a4 patches: 578995,11, 579572,2
16 seconds later.

I haven't copied in the change ids "578995,11, 579572,2" this time, but I think (not sure tho) I have made a demo of those ca. 2 weeks ago, then deleted it. It's very likely that I've copied those change ids into the textarea at one point.

This happened the second time now, first time 2 days before. I don't remember if the patches were the same, I've deleted the demo very quickly.

Are these stuck somewhere in a queue?

I've created another demo: 16d4afb6c4012cac810121fdbbfce904
and it has a twin too: 4cb27da34f62e845d77be74526fb149c
different change ids...

This is spooky...

The resource loader caches can grow up to a few MB, meaning there is not room for multiple wikis at the same domain:

Options:

• Disable resource loader local storage, we already do this for Firefox. Not sure if this can be done via config.
• Write a custom script that clears the RL cache of any other wikis in your localStorage whenever you visit a patchdemo wiki, then add this to common.js or similar.

I've just noticed I can't link to Commons images or upload an image. I'd prefer to do the first. Is it possible to enable this?
I think it's only one localsetting: $wgUseInstantCommons = true;

Maybe once per day? Merged patches can be tested on the beta cluster, this would be a pretty good way to disk usage in check. Depends on #4

In recently created wikis, abusefilter and flaggedrevs tables are not being created.

We can either wait for an upstream fix or just run update.php when creating new wikis.

As mentioned in #54 (comment) and also from experience, when creating a wiki that updates an old patchset, it can be annoying to update links already shared to the new wiki.

Now that we also have to the patchdemobot on Phabricator, it is also impossible for those posts to be updated by other users.

We could add an option when deleting a wiki to specify a wiki to redirect to.

For example, if I just want to test out an old version of MW.

1. Choose REL1_34 from the dropdown.
2. Enter 616561 as the change to apply (this is just the latest patch in that branch)
3. Observe the following log tail:

+ IFS=' '
+ read -r repo dir
+ git --git-dir=/var/www/html/repositories/mediawiki/skins/Vector/.git worktree prune
+ git --git-dir=/var/www/html/repositories/mediawiki/skins/Vector/.git worktree add --detach /var/www/html/wikis/d5d270e90e6aae078743b97cea9d93e1/w/skins/Vector origin/REL1_34
Preparing worktree (detached HEAD f39a3f0)
HEAD is now at f39a3f0 vector.js: Remove eager calculation of p-cactions width on page load
+ IFS=' '
+ read -r repo dir
+ git --git-dir=/var/www/html/repositories/mediawiki/services/parsoid/.git worktree prune
+ git --git-dir=/var/www/html/repositories/mediawiki/services/parsoid/.git worktree add --detach /var/www/html/wikis/d5d270e90e6aae078743b97cea9d93e1/w/parsoid origin/REL1_34
fatal: invalid reference: origin/REL1_34
Could not install the wiki.

This same error occurs with other older versions.

After we resolve all the patches to apply, iff they are all merged and the wiki is against master, then we could warn the user they they could test on beta instead.

The warning could be an OOUI dialog using the script tag hack. On clicking OK they would reload the page with some bypass query string param.

Follow-up to #32. Non-breaking, low-prio.
I've applied 2 patches, both Depends-On: the same patch. The latter was applied twice without causing any issues, but unnecessarily:

http://patchdemo.wmflabs.org/wikis/87ff0eb77076404c5541ac861a7eb158/w/

606306,17: checkboxHack: Trigger 'input' event when checkbox state changes
607404,1: [DNM][Patchdemo] Default to modern layout
606306,17: checkboxHack: Trigger 'input' event when checkbox state changes
606538,16: checkboxHack: Handle SPACE and ENTER key on button (label) to change checkbox state

In addition 606306,17 comes after 606538,16 in the chain, thus applying that can be eliminated too. As I see patches in chains are applied individually, thus keeping a set of already applied patches should be easy.

As discussed when this feature was merged (#95) there are problems with storing the page title as the filename:

• Windows doesn't like colons : and probably other punctuation that is valid in a page title
• All OSes won't allow / in a filename, i.e. subpages

Other options:

• Use a descriptive filename, then store the title in the first line of the file
  • Easy to read/create
  • Requires a more complex script to import
• Use the [[Special:Export]] XML format
  • Can be imported using existing scripts
  • Can store author/page history if required

cc @catrope @MatmaRex

For development and demonstration it would be preferable to have the new Vector layout as default.
LocalSettings:

$wgVectorDefaultSkinVersion = '2';
$wgVectorDefaultSkinVersionForExistingAccounts = '2'; // I guess this is not necessary.
$wgVectorDefaultSkinVersionForNewAccounts = '2';

Creating demos fail with the following message:

+ php /var/www/html/wikis/de9703c9100b489f06cde4c3de39eef8/w/maintenance/install.php --dbname=patchdemo_de9703c9100b489f06cde4c3de39eef8 --dbuser=patchdemo --dbpass=patchdemo --confpath=/var/www/html/wikis/de9703c9100b489f06cde4c3de39eef8/w --server=http://patchdemo.wmflabs.org --scriptpath=/wikis/de9703c9100b489f06cde4c3de39eef8/w --with-extensions --pass=patchdemo1 'Patch Demo (585851,26)' 'Patch Demo'
A dependency error was encountered while installing the extension "DiscussionTools": Could not find the registration file for the extension "Linter"

Could not install the wiki.

It takes several minutes to run on the full wikis folder, and all it does is free up some disk space.

Tl;dr:
This only applies to the first patch in each repo. The rest (if there are more) can only be merged.
Repos that have no patch applied are still checked out at HEAD. A next step could be to checkout each repo's master branch at the time the first patch was submitted.

Reason:
Many time there are conflicting patches merged that cause the demo creation to fail. This often happens with old patches, but it can even happen in the meantime while waiting for jenkinsbot to approve the patch. Should the conflicting patch contain renames or refactorings, a lengthy rebase is necessary, that can be up to a few hours for massive patches or chains. Often rebasing proof-of-concept solutions has no benefit, it's just lost time.

Detailed algorithm:
For each repository:

• Instead of checking out the HEAD, check out the commit of the first patch directly.
  • Allow the use of merged patches / commit hash to choose the version to check out.
• Then merge the rest of the patches for that repo.
• If no patches are applied for a repo then check out the HEAD.
  • Alternatively: check out the commit merged before the first patch's submit time.

Prio: would be awesome.

As we are continually posting links to wikis and then deleting them, we should probably have a 404 handler that explains this.

We could then tie each instance to a username, which would help us keep an eye on abuse of the system. We could also allow users to delete their own instances.

Accept changeset numbers in the format: 578568,12

It so happened that I needed to test a previous PS. I had to resubmit as the last PS.
Low prio.

I was trying to create a demo for https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/592325

The previous patch in chain fails the build, I can't do anything about that.

Demo creation failed because of this:

Querying patch metadata...
https://gerrit.wikimedia.org/r/changes/?q=change:592325&o=LABELS&o=CURRENT_REVISION
https://gerrit.wikimedia.org/r/changes/mediawiki%2Fskins%2FVector~master~I182eedeff0b6eb62250f2682b89f30c8ff0f70de/revisions/ae3b99d9a3c4a1708936eda50ef883e4eb3c3c60/related
https://gerrit.wikimedia.org/r/changes/592325/revisions/5/commit
https://gerrit.wikimedia.org/r/changes/584694/revisions/25/commit
https://gerrit.wikimedia.org/r/changes/?q=change:I8e153c0ab927f9d880a68fb9efb0bf37b91d26b2&o=LABELS&o=CURRENT_REVISION
Patch must be approved (Verified+2) by jenkins-bot

I'm solving this by squashing the two patches, however that's not optimal as now the patch is not useful to present the changes I've applied.

Optional: Futhermore, it would be helpful to have an option to create a demo with an unapproved patch. jenkinsbot does certain strict tests that are necessary to pass for live code, but not for demonstration code. Sometimes it's not worth the time it takes to investigate and fix every issue jenkins reports.

Lots of extensions register beta features, and some functionality can only be tested by enabling a beta feature. See also #19.

For example, a patchdemobot account could post the following on linked Phab tasks:

Matmarex created a wiki with patches linked to this task at https://patchdemo.wmflabs.org/...

This would improve visibility to non technical users watching the task.

The feature could be disabled via a checkbox in the form.

Possible shouldn't even be enabled by default, as it isn't on most wikis, but as we don't allow users to change the config yet, we should at least make the give the default user appropriate permissions (autoreview etc.)