Skip to content

ad-freiburg/wikidata-query-gui

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Wikibase Query Service GUI

This repository contains the GUI for the Wikidata Query Service.

Please see more details about the service in the User Manual.

Download & setup

Clone git repo, go into created folder and then pull all dependencies via npm package manager.

$ git clone https://gerrit.wikimedia.org/r/wikidata/query/gui
$ cd gui
$ npm install

Alternatively, use npm install.

npm install wikidata-query-gui

Configuration

Per default the Wikibase Query Service GUI is configured to be used as a local development test instance. It can be customized by creating a custom-config.json in the repository's root dir. This file can be used to override any of the default settings obtained from default-config.json.

Banner Message

The banner message may be configured per site deployment. In order display a banner, add its banner key to the configuration:

{
// ...
  "bannerName": "query-builder",
// ...
}

Empty values, falsy values and undefined banner keys will result in the banner not showing.

Run tests

Run eslint, JSHint, JSCS and QUnit tests.

$ npm test

Autofix eslint errors

$ npm run grunt eslint -- --fix

Browser tests

It is recommended to use Fresh to run the browser tests.

$ npm run browser_test

Running browser tests headlessly inside a container can make debugging difficult. You can record videos of the browser running the tests by executing the following commands inside the fresh container:

export DISPLAY=:94
/usr/bin/Xvfb "$DISPLAY" -screen 0 1280x1024x24 -ac -nolisten tcp &

npm run browser_test

Debug

Start a test server for local debugging. Do not use it in production.

$ npm start

Build

Create a build with bundled and minified files.

$ npm run build

Local development

Build image locally:

DOCKER_BUILDKIT=1 docker build --target production -f .pipeline/blubber.yaml .

Run image:

docker run -p 8080:8080 <image name>

Visit http://127.0.0.1:8080/

Publish new image version

To create a new image version merge your change into the main branch.

This triggers the publish-image pipeline. Image is available at docker-registry.wikimedia.org/repos/wmde/wikidata-query-gui:<timestamp>

Deploy in WMF environment (query.wikidata.org)

Important

This codebase is not automatically deployed by some CD or by the train.

After merging code and a new image being built, this code must be promptly deployed the WMF environments. (why?)

If you merge code here it is your responsibility to ensure it is promptly deployed; either by doing it yourself or by finding someone to do it for you.

After the code changes have been merged and new container image version has been published to Wikimedia registry, change the version tag passed into the Helm chart used for deployments by making and approving the change in helmfile.d/services/wikidata-query-gui/values.yaml in WMF's deployment-charts.

Once the new deployment chart has been created, change the deployment chart version in use on the deployment server following instructions on https://wikitech.wikimedia.org/wiki/Kubernetes/Deployments. A bit more detailed deployment instructions for another service, that could be used for reference, can be found at https://wikitech.wikimedia.org/wiki/Miscweb#Deploy\_to\_Kubernetes/wikikube.

Why we must deploy promptly

We don't want to stack up undeployed changes because we might not discover issues with the change until we do a deploy a long time in the future.

This will confuse future deployers (which might be you!) if they find an issue or changes unrelated to code they think they are deploying.

Even if there is only a single change waiting and deploying a long time in the future will likely mean you have forgotten the context of the change making it harder to debug and reason with.

Keeping the Lead Time for Changes low has been identified as a key metric to for high performing software teams.

Usage Metrics

Usage metrics are only emitted when hosted on query.wikidata.org. They are sent to https://wikidata.org/beacon/stats and https://wikidata.org/beacon/statsv .

Components

Editor

A CodeMirror based SPARQL editor with code completion (ctrl+space) and tooltips (hover).

var editor = new wikibase.queryService.ui.editor.Editor();
editor.fromTextArea( $( '.editor' )[0] );

See examples/editor.html.

Example dialog

A dialog that allows browsing of SPARQL examples.

new wikibase.queryService.ui.dialog.QueryExampleDialog(  $element, querySamplesApi, callback, previewUrl );

See examples/dialog.html.

SPARQL

var api = new wikibase.queryService.api.Sparql();
api.query( query ).done( function() {
	var json = JSON.parse( api.getResultAsJson() );

} );

See examples/sparql.html. JSFiddle.net

Result Views

Views that allow rendering SPARQL results (see documentation).

var api = new wikibase.queryService.api.Sparql();
api.query( query ).done(function() {
	var result = new wikibase.queryService.ui.resultBrowser.CoordinateResultBrowser();
	result.setResult( api.getResultRawData() );
	result.draw( element );
} );

See examples/result.html. JSFiddle.net

Release Notes and npm package

Unfortunately there are no releases and the provided code and interfaces are not considered to be stable. Also the dist/ folder contains a build that may not reflect the current code on master branch.