dcausse created this task.
dcausse added a project: Wikidata-Query-Service.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
Currently the release process for wdqs is error prone. Note that `gui` is a
maven submodule **and** a git submodule.
1. take master of `wikidata/query/rdf` locally
2. bump the snapshot version (e.g. 0.3.4-SNAPSHOT -> 0.3.5-SNAPSHOT)
3. push to gerrit a change for this to `wikidata/query/rdf` and
`wikidata/query/gui`
4. merge the gerrit patches
5. run mvn to deploy the artifacts to the archiva repository (snapshot)
- This will generate the zip distribution containing both the server and
the gui used by https://github.com/wmde/wikibase-docker for wdqs related images
To prepare the deployment of the server side components we must use the
`wikidata/query/deploy` repository:
- delete the old snapshot and add the new ones for the `blazegraph-service`
and `lib/wikidata-query-tools-X.Y.Z-SNAPSHOT-jar-with-dependencies.jar`
artifacts, example commit:
https://gerrit.wikimedia.org/r/c/wikidata/query/deploy/+/550342
To prepare the deployment of the client side components we must use the same
`wikidata/query/deploy`repository:
- bump the `gui` submodule to the commit ref we want to deploy (e.g.
https://gerrit.wikimedia.org/r/c/wikidata/query/deploy/+/549831)
The problems of this procedure are:
1. There are no guarantees that the version in archiva matches what is
committed in the git repository, since we push to archiva on the same working
copy as the one used to bump the version there are no guarantees that the
version bump commit does not become a merge commit once validated in gerrit or
worse being rebased after the fact.
2. `gui` being a git submodule of `wikidata/query/rdf` is confusing and error
prone, the gui is being developed on its own repo but when bumping the snapshot
version of `wikidata/query/rdf` we create a separate commit for it. Meaning
that this repo has two independent sources of changes.
There could be two strategies to strengthen the release process of this
project and both of them requires getting rid of the `gui` submodule.
A single repository
-------------------
Move the `gui` project directly inside `wikidata/query/rdf`.
- pros:
- A single unified release process for the server and the client and the
zip distribution managed by the maven release plugin
- cons:
- needs to release everything if either the gui or the server needs an
update (already the case today for the zip distribution)
- git history is lost on the `gui`
- find solutions for the deploy preparation:
- unclear if scap is able to do some preparation (unzip a file prio to
deploying). The gui would be available as jar file from archiva
- if scap is not able to do this we still need a `gui` submodule and have
it updated to the tag created by `maven release`
Separate repositories
---------------------
Remove the `gui` submodule from `wikidata/query/rdf`.
- pros
- independent release processes for the gui and the server (which reflect
reality of the development)
- can use the maven release plugin for `wikidata/query/rdf` and have real
versions
- unchanged deployment preparation on `wikidata/query/deploy`
- cons
- requires a new repository to manage the distribution of the zip file that
contains
- 3 steps release process:
- server, gui and the zip distribution
TASK DETAIL
https://phabricator.wikimedia.org/T238303
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: dcausse
Cc: Aklapper, Mathew.onipe, Gehel, Lucas_Werkmeister_WMDE, Addshore, dcausse,
darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden,
EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer,
jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles,
Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
