Do the demo require a server side backend or are they 100% executing in the browser? If we need to serve content, that would need to be done on another server. Else, it is "just" about enhancing the doc jobs to publish the demo to the document root.

(In reply to comment #1)

Do the demo require a server side backend or are they 100% executing in the
browser? If we need to serve content, that would need to be done on another
server. Else, it is "just" about enhancing the doc jobs to publish the demo
to
the document root.

Fully stand-alone client-side JS only, providing static files. Theoretically they could just be linked off beta's bits – e.g. http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/lib/ve/demos/ve/eventLogger.html – but this is ugly (and doesn't work for OOjs UI because it's only deployed in compiled form without demos).

This is similar to bug 58620. Since the OOjs UI demos require nodejs/npm setup similar to building the KSS documentation, fixing this will require similar steps as hashar outlined in comment 1 there.

Once we have dev.wikimedia.org up and running, we should migrate documentation to there, which will help remove the awkward terminology overlap/ambiguity between "documentation" and "demo". We'd e.g. have:

• dev.wikimedia.org/visualeditor/documentation/
• dev.wikimedia.org/visualeditor/demo/

But for the time being on doc.wikimedia.org, we can just do the same and don't mind the fact that there is already "doc" in the url somewhere.

So there's nothing blocking us from having additional directories up on doc.wikimedia.org. The blocking aspects of this are specific to each project.

In T62143#666023, @Spage wrote:

This is similar to bug 58620. Since the OOjs UI demos require nodejs/npm setup similar to building the KSS documentation, fixing this will require similar steps as hashar outlined in comment 1 there.

The blocker for OOjs UI is being able to run Grunt and arbitrary npm dependencies on the server. Which is blocked on migrating that job from gallium to labs slaves.

For VisualEditor, the main blocker was directory management (it doesn't require a build step).

Can you ship the demo directly in the doc ? Ie: https://doc.wikimedia.org/visualeditor/v0.1.0/doc/demos/ ? The demos could be linked from the documentation main page.

In T62143#962939, @hashar wrote:

Can you ship the demo directly in the doc ? Ie: https://doc.wikimedia.org/visualeditor/v0.1.0/doc/demos/ ? The demos could be linked from the documentation main page.

No, they don't nest well and are independent web entry points. Keep them as doc/ and demos/. The doc/ dir is auto-generated and managed by jsduck. The demo/ on the other hand is in git and should work after a plain git clone and running install/build.

From https://www.mediawiki.org/wiki/Continuous_integration/meetings/2015-03-30/minutes

We should be able to craft a job that triggers doc-publish-sync job with source /demos/ and dest /visualeditor/<version>/demos/ . The job would be triggered on postmerge.

I have not much time available to handle this though. So it is going to sit in the backlog for now :/

That is similar to T87490: Publish QUnit coverage on integration.wikimedia.org.

In T62143#1162486, @hashar wrote:

We should be able to craft a job that triggers doc-publish-sync job with source /demos/ and dest /visualeditor/<version>/demos/ . The job would be triggered on postmerge.

The main blocker for this used to be the ability to run a build script. That is resolved now that we migrated jsduck to labs. The OOjs UI publication job for documentation already makes use of npm-install (example).

The main this this is blocked on now is:

• Setting up a redirect.
• Upstream OOjs UI and VisualEditor need to have their demo-directory be standalone (like docs). So must not reference ../ but instead build and copy relevant files.

After that, it's just a simple change to update publication job to call push-doc a second time (once for docs/ to visualeditor/:version and a second time for demos/ to visualeditor/:version/demo

That is similar to T87490: Publish QUnit coverage on integration.wikimedia.org.

That one is primarily blocked on T93558: Add publishing macro for integration.wikimedia.org/cover. Trivial otherwise.

Timo worked on generic templates to publish /cover/ directories. It can be reused now to publish the /demos/ directories.

In T62143#1165994, @Krinkle wrote:

The main this this is blocked on now is:

• Setting up a redirect.

Redirect for what?

• Upstream OOjs UI and VisualEditor need to have their demo-directory be standalone (like docs). So must not reference ../ but instead build and copy relevant files.

For OOUI, rGOJUe538462cbd8f: demos: Make self-contained in demos/ directory introduces a npm demos command to build the standalone demos directory.