We currently have several projects which can not be tested with our current Jenkins test infrastructure, and as a consequence are hosting their primary code repositories on github: * RESTBase https://github.com/wikimedia/restbase -- missing Cassandra support * iOS Mobile app https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083005.html -- missing OS X platform
Other projects can only run a small portion of their test suite via Jenkins: * mw-ocg-latexer https://github.com/wikimedia/mediawiki-extensions-Collection-OfflineContentGenerator-latex_renderer -- requires LaTeX from PPA, image utilities (`jpegtran`).
An alternative to allow these apps to be hosted on Wikimedia infrastructure (gerrit, eventually phabricator) is to allow travis integration with jenkins as an optional service.
npm-travis https://github.com/cscott/npm-travis ( https://github.com/cscott/npm-travis) is a tool which will trigger Travis builds from NPM by pushing to a throwaway branch, which is then cleaned up after the tests complete. It integrates well with the Gerrit access control mechanism: the "Travis Bot" user can be granted push access only, and only to branches prefixed with `npm-travis/`, so it cannot be used to push changes to the master or deployment branches.
This isn't a replacement for our jenkins test infrastructure, but it allows us to accommodate oddball repositories without taxing our infrastructure team or resorting to offsite repository hosting.
There are WIP patches for integrating `npm-travis` with our jenkins infrastructure (https://gerrit.wikimedia.org/r/173045, https://gerrit.wikimedia.org/r/173046) but they seem to be blocked on policy disagreements. This RFC aims to resolve the policy issues.
This RFC in Phabricator: https://phabricator.wikimedia.org/T114421 --scott
<quote name="C. Scott Ananian" date="2015-10-01" time="16:43:52 -0400">
- iOS Mobile app
https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083005.html
missing OS X platform
If you want the gory details about the iOS decision, see: https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Retrospectives/Retrospect...
Summary: Ain't nobody got time for maintaining OSX machines.
This RFC in Phabricator: https://phabricator.wikimedia.org/T114421
Related, but slightly different: https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Code_revie...
Related in that its about code-review, which has implications for CI, but different because code-review can happen one place (Differential) while CI can happen somewhere else (Travis).
I still feel extremely strongly that having a 90/10 split of repos on Gerrit/Github only hurts our engineering community health. You can read more of that reasoning in the above (draft) guideline and in this document describing why we want to migrate to Differential: https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Gerrit_mig...
Greg
On 1 October 2015 at 22:43, C. Scott Ananian cananian@wikimedia.org wrote:
We currently have several projects which can not be tested with our current Jenkins test infrastructure, and as a consequence are hosting their primary code repositories on github:
- RESTBase https://github.com/wikimedia/restbase -- missing Cassandra
support
- iOS Mobile app
< https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083005.html
-- missing OS X platform
While hosted officially on Gerrit, Citoid should be added to this list as well. Its proper functioning depends on Zotero being available, so the current CI tests for Citoid include only syntax checking via jshint. In this case, however, it is unlikely that Travis would help. Ideally, isolated CI instances would allow us to have a Zotero container that could be spun alongside Citoid during tests.
Cheers, Marko
Other projects can only run a small portion of their test suite via Jenkins:
- mw-ocg-latexer
< https://github.com/wikimedia/mediawiki-extensions-Collection-OfflineContentG...
-- requires LaTeX from PPA, image utilities (`jpegtran`).
An alternative to allow these apps to be hosted on Wikimedia infrastructure (gerrit, eventually phabricator) is to allow travis integration with jenkins as an optional service.
npm-travis https://github.com/cscott/npm-travis ( https://github.com/cscott/npm-travis) is a tool which will trigger Travis builds from NPM by pushing to a throwaway branch, which is then cleaned up after the tests complete. It integrates well with the Gerrit access control mechanism: the "Travis Bot" user can be granted push access only, and only to branches prefixed with `npm-travis/`, so it cannot be used to push changes to the master or deployment branches.
This isn't a replacement for our jenkins test infrastructure, but it allows us to accommodate oddball repositories without taxing our infrastructure team or resorting to offsite repository hosting.
There are WIP patches for integrating `npm-travis` with our jenkins infrastructure (https://gerrit.wikimedia.org/r/173045, https://gerrit.wikimedia.org/r/173046) but they seem to be blocked on policy disagreements. This RFC aims to resolve the policy issues.
This RFC in Phabricator: https://phabricator.wikimedia.org/T114421
--scott
(http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Oct 2, 2015 at 6:15 AM, Marko Obrovac mobrovac@wikimedia.org wrote:
While hosted officially on Gerrit, Citoid should be added to this list as well. Its proper functioning depends on Zotero being available, so the current CI tests for Citoid include only syntax checking via jshint. In this case, however, it is unlikely that Travis would help. Ideally, isolated CI instances would allow us to have a Zotero container that could be spun alongside Citoid during tests.
Travis provides isolated containers or VMs, so should be able to test Zotero if there is a version of Zotero that is compatible with the Travis default image.
Gabriel
- iOS Mobile app
< https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083005.html
I saw npm-travis when you announced it a while back and was intrigued. The master branch on the wikipedia-ios repo is already building successfully on Travis, so feel free to try triggering builds if that helps with the experiment—but please don't push to master :-). I bet the Android team would also be interested in trying this out to alleviate some of the burden they've shouldered getting our own CI to run Android builds & tests.
Ideally,
isolated CI instances would allow us to have a Zotero container that could be spun alongside Citoid during tests.
Gabriel beat me to it, but here's a link to docs about using Docker w/in Travis http://docs.travis-ci.com/user/docker/. Also, is Zotero stateless? I'd caution against having persistent staging/test service instances to avoid problems caused by:
- Accumulated state - Multiple tests being run in parallel
Regarding npm-travis specifically, who would own it? It doesn't seem too complex (push to a GitHub repo, get the job id, poll its state), but would C. Scott continue working on it or would RelEng claim it as part of the infrastructure they maintain?
Lastly, it appears that Travis's build-triggering API is still in beta http://docs.travis-ci.com/user/triggering-builds/, and there's no mention of polling builds in this way. If someone were to try using this with one or more projects (e.g. Android) and decide to move forward, would we reach out to Travis to ask when the current API will be marked as stable or if they would be willing to work with us to develop an API more suited to our needs? I'm all about doing what it takes to get the job done*, but just wanted to be sure that were aware that this might not be the most stable way to use Travis. I also did a quick search to see if there's precedent for this, and found:
- travis-build-watcher https://www.npmjs.com/package/travis-build-watcher: this is the closest I could find to something that pushes to GitHub to trigger builds & monitor them - node-travis-ci https://github.com/pwmckenna/node-travis-ci: not equivalent to npm-travis, but might simplify it if didn't want to re-implement a JS client for Travis
* iOS team is using a collection of tools called fastlane https://github.com/KrauseFx/fastlane which build, test, and release our app—including using the undocumented (AFAIK) API for iTunes Connect (Apple's service for uploading & managing apps in the App Store). That said, it's widely used, has 90 contributors, and is being actively maintained by the owner.
On Fri, Oct 2, 2015 at 9:15 AM, Marko Obrovac mobrovac@wikimedia.org wrote:
On 1 October 2015 at 22:43, C. Scott Ananian cananian@wikimedia.org wrote:
We currently have several projects which can not be tested with our
current
Jenkins test infrastructure, and as a consequence are hosting their
primary
code repositories on github:
- RESTBase https://github.com/wikimedia/restbase -- missing Cassandra
support
- iOS Mobile app
<
https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083005.html
-- missing OS X platform
While hosted officially on Gerrit, Citoid should be added to this list as well. Its proper functioning depends on Zotero being available, so the current CI tests for Citoid include only syntax checking via jshint. In this case, however, it is unlikely that Travis would help. Ideally, isolated CI instances would allow us to have a Zotero container that could be spun alongside Citoid during tests.
Cheers, Marko
Other projects can only run a small portion of their test suite via Jenkins:
- mw-ocg-latexer
<
https://github.com/wikimedia/mediawiki-extensions-Collection-OfflineContentG...
-- requires LaTeX from PPA, image utilities (`jpegtran`).
An alternative to allow these apps to be hosted on Wikimedia
infrastructure
(gerrit, eventually phabricator) is to allow travis integration with jenkins as an optional service.
npm-travis https://github.com/cscott/npm-travis ( https://github.com/cscott/npm-travis) is a tool which will trigger
Travis
builds from NPM by pushing to a throwaway branch, which is then cleaned
up
after the tests complete. It integrates well with the Gerrit access control mechanism: the "Travis Bot" user can be granted push access only, and only to branches prefixed with `npm-travis/`, so it cannot be used to push changes to the master or deployment branches.
This isn't a replacement for our jenkins test infrastructure, but it
allows
us to accommodate oddball repositories without taxing our infrastructure team or resorting to offsite repository hosting.
There are WIP patches for integrating `npm-travis` with our jenkins infrastructure (https://gerrit.wikimedia.org/r/173045, https://gerrit.wikimedia.org/r/173046) but they seem to be blocked on policy disagreements. This RFC aims to resolve the policy issues.
This RFC in Phabricator: https://phabricator.wikimedia.org/T114421
--scott
(http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Marko Obrovac, PhD Senior Services Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Also, sorry if this all should've gone in Phab and not email. I can transcribe to Phab if we'd rather continue discussion there.
On Fri, Oct 2, 2015 at 11:50 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
- iOS Mobile app
< https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083005.html
I saw npm-travis when you announced it a while back and was intrigued. The master branch on the wikipedia-ios repo is already building successfully on Travis, so feel free to try triggering builds if that helps with the experiment—but please don't push to master :-). I bet the Android team would also be interested in trying this out to alleviate some of the burden they've shouldered getting our own CI to run Android builds & tests.
Ideally,
isolated CI instances would allow us to have a Zotero container that could be spun alongside Citoid during tests.
Gabriel beat me to it, but here's a link to docs about using Docker w/in Travis http://docs.travis-ci.com/user/docker/. Also, is Zotero stateless? I'd caution against having persistent staging/test service instances to avoid problems caused by:
- Accumulated state
- Multiple tests being run in parallel
Regarding npm-travis specifically, who would own it? It doesn't seem too complex (push to a GitHub repo, get the job id, poll its state), but would C. Scott continue working on it or would RelEng claim it as part of the infrastructure they maintain?
Lastly, it appears that Travis's build-triggering API is still in beta http://docs.travis-ci.com/user/triggering-builds/, and there's no mention of polling builds in this way. If someone were to try using this with one or more projects (e.g. Android) and decide to move forward, would we reach out to Travis to ask when the current API will be marked as stable or if they would be willing to work with us to develop an API more suited to our needs? I'm all about doing what it takes to get the job done*, but just wanted to be sure that were aware that this might not be the most stable way to use Travis. I also did a quick search to see if there's precedent for this, and found:
- travis-build-watcher
https://www.npmjs.com/package/travis-build-watcher: this is the closest I could find to something that pushes to GitHub to trigger builds & monitor them
- node-travis-ci https://github.com/pwmckenna/node-travis-ci: not
equivalent to npm-travis, but might simplify it if didn't want to re-implement a JS client for Travis
- iOS team is using a collection of tools called fastlane
https://github.com/KrauseFx/fastlane which build, test, and release our app—including using the undocumented (AFAIK) API for iTunes Connect (Apple's service for uploading & managing apps in the App Store). That said, it's widely used, has 90 contributors, and is being actively maintained by the owner.
On Fri, Oct 2, 2015 at 9:15 AM, Marko Obrovac mobrovac@wikimedia.org wrote:
On 1 October 2015 at 22:43, C. Scott Ananian cananian@wikimedia.org wrote:
We currently have several projects which can not be tested with our
current
Jenkins test infrastructure, and as a consequence are hosting their
primary
code repositories on github:
- RESTBase https://github.com/wikimedia/restbase -- missing Cassandra
support
- iOS Mobile app
<
https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083005.html
-- missing OS X platform
While hosted officially on Gerrit, Citoid should be added to this list as well. Its proper functioning depends on Zotero being available, so the current CI tests for Citoid include only syntax checking via jshint. In this case, however, it is unlikely that Travis would help. Ideally, isolated CI instances would allow us to have a Zotero container that could be spun alongside Citoid during tests.
Cheers, Marko
Other projects can only run a small portion of their test suite via Jenkins:
- mw-ocg-latexer
<
https://github.com/wikimedia/mediawiki-extensions-Collection-OfflineContentG...
-- requires LaTeX from PPA, image utilities (`jpegtran`).
An alternative to allow these apps to be hosted on Wikimedia
infrastructure
(gerrit, eventually phabricator) is to allow travis integration with jenkins as an optional service.
npm-travis https://github.com/cscott/npm-travis ( https://github.com/cscott/npm-travis) is a tool which will trigger
Travis
builds from NPM by pushing to a throwaway branch, which is then cleaned
up
after the tests complete. It integrates well with the Gerrit access control mechanism: the "Travis Bot" user can be granted push access
only,
and only to branches prefixed with `npm-travis/`, so it cannot be used
to
push changes to the master or deployment branches.
This isn't a replacement for our jenkins test infrastructure, but it
allows
us to accommodate oddball repositories without taxing our infrastructure team or resorting to offsite repository hosting.
There are WIP patches for integrating `npm-travis` with our jenkins infrastructure (https://gerrit.wikimedia.org/r/173045, https://gerrit.wikimedia.org/r/173046) but they seem to be blocked on policy disagreements. This RFC aims to resolve the policy issues.
This RFC in Phabricator: https://phabricator.wikimedia.org/T114421
--scott
(http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Marko Obrovac, PhD Senior Services Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
On Fri, Oct 2, 2015 at 11:50 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
Lastly, it appears that Travis's build-triggering API is still in beta
http://docs.travis-ci.com/user/triggering-builds/, and there's no mention
of polling builds in this way.
I don't use this API, and it's not really suitable in any case. I just use the standard stable API for watching builds on a branch. Trigger is automatic with the push, which is a boring old git push, via the git CLI.
If someone were to try using this with one
or more projects (e.g. Android) and decide to move forward, would we reach out to Travis to ask when the current API will be marked as stable or if they would be willing to work with us to develop an API more suited to our needs?
Not sure exactly what that would be. The only oddity in the current setup is that I clean up the branch right after the build is complete -- but that's not an inherent property of the process. If we wanted to keep build artifacts around "forever", we could easily do so; I just wanted to ensure things were uncluttered in the github "branches" pulldown.
I'm all about doing what it takes to get the job done*, but just
wanted to be sure that were aware that this might not be the most stable way to use Travis.
There's nothing unusual about triggering travis builds by pushing to a branch.
The only thing that's interesting at all is that our branch names have slashes in them, and that issue was resolved a year ago: https://github.com/travis-ci/travis-api/pull/146
That property of our branch names was also optional; we used dashes instead of slashes as a workaround. But it does let us integrate better with gerrit access control mechanisms, which are built around slash-delimited branch names. --scott
Ah of course, my misunderstanding. (I even mentioned pushing to git in my last email).
If we wanted to keep build artifacts around "forever", we could easily do so;
How would you get artifacts of a build done inside a Travis VM?
In any case, this still involves going through GitHub. Is anyone evaluating GitLab-CI https://about.gitlab.com/gitlab-ci/? Apparently their "runner" service can run on OSX (and Windows & Linux).
On Fri, Oct 2, 2015 at 1:20 PM, C. Scott Ananian cananian@wikimedia.org wrote:
On Fri, Oct 2, 2015 at 11:50 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
Lastly, it appears that Travis's build-triggering API is still in beta
http://docs.travis-ci.com/user/triggering-builds/, and there's no mention
of polling builds in this way.
I don't use this API, and it's not really suitable in any case. I just use the standard stable API for watching builds on a branch. Trigger is automatic with the push, which is a boring old git push, via the git CLI.
If someone were to try using this with one
or more projects (e.g. Android) and decide to move forward, would we
reach
out to Travis to ask when the current API will be marked as stable or if they would be willing to work with us to develop an API more suited to
our
needs?
Not sure exactly what that would be. The only oddity in the current setup is that I clean up the branch right after the build is complete -- but that's not an inherent property of the process. If we wanted to keep build artifacts around "forever", we could easily do so; I just wanted to ensure things were uncluttered in the github "branches" pulldown.
I'm all about doing what it takes to get the job done*, but just
wanted to be sure that were aware that this might not be the most stable way to use Travis.
There's nothing unusual about triggering travis builds by pushing to a branch.
The only thing that's interesting at all is that our branch names have slashes in them, and that issue was resolved a year ago: https://github.com/travis-ci/travis-api/pull/146
That property of our branch names was also optional; we used dashes instead of slashes as a workaround. But it does let us integrate better with gerrit access control mechanisms, which are built around slash-delimited branch names. --scott
-- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Travis is not integrated with gitlab, so it's not really relevant here. *If* travis adds gitlab integration *and* we switch our current github mirror to gitlab *then* it could be something to look at. Neither of those preconditions are currently met.
We're not using any "new" github features, just the standard github mirror that gerrit already maintains (and presumably any future change review system would as well). --scott
On Fri, Oct 2, 2015 at 7:00 PM, Brian Gerstle bgerstle@wikimedia.org wrote:
Ah of course, my misunderstanding. (I even mentioned pushing to git in my last email).
If we wanted to keep build artifacts around "forever", we could easily do so;
How would you get artifacts of a build done inside a Travis VM?
In any case, this still involves going through GitHub. Is anyone evaluating GitLab-CI https://about.gitlab.com/gitlab-ci/? Apparently their "runner" service can run on OSX (and Windows & Linux).
On Fri, Oct 2, 2015 at 1:20 PM, C. Scott Ananian cananian@wikimedia.org wrote:
On Fri, Oct 2, 2015 at 11:50 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
Lastly, it appears that Travis's build-triggering API is still in beta
http://docs.travis-ci.com/user/triggering-builds/, and there's no mention
of polling builds in this way.
I don't use this API, and it's not really suitable in any case. I just
use
the standard stable API for watching builds on a branch. Trigger is automatic with the push, which is a boring old git push, via the git CLI.
If someone were to try using this with one
or more projects (e.g. Android) and decide to move forward, would we
reach
out to Travis to ask when the current API will be marked as stable or
if
they would be willing to work with us to develop an API more suited to
our
needs?
Not sure exactly what that would be. The only oddity in the current
setup
is that I clean up the branch right after the build is complete -- but that's not an inherent property of the process. If we wanted to keep
build
artifacts around "forever", we could easily do so; I just wanted to
ensure
things were uncluttered in the github "branches" pulldown.
I'm all about doing what it takes to get the job done*, but just
wanted to be sure that were aware that this might not be the most
stable
way to use Travis.
There's nothing unusual about triggering travis builds by pushing to a branch.
The only thing that's interesting at all is that our branch names have slashes in them, and that issue was resolved a year ago: https://github.com/travis-ci/travis-api/pull/146
That property of our branch names was also optional; we used dashes
instead
of slashes as a workaround. But it does let us integrate better with
gerrit
access control mechanisms, which are built around slash-delimited branch names. --scott
-- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Right, but GitLab apparently has its own CI offering, so we wouldn't need to wait for Travis to integrate.
On Friday, October 2, 2015, C. Scott Ananian cananian@wikimedia.org wrote:
Travis is not integrated with gitlab, so it's not really relevant here. *If* travis adds gitlab integration *and* we switch our current github mirror to gitlab *then* it could be something to look at. Neither of those preconditions are currently met.
We're not using any "new" github features, just the standard github mirror that gerrit already maintains (and presumably any future change review system would as well). --scott
On Fri, Oct 2, 2015 at 7:00 PM, Brian Gerstle <bgerstle@wikimedia.org javascript:;> wrote:
Ah of course, my misunderstanding. (I even mentioned pushing to git in my last email).
If we wanted to keep build artifacts around "forever", we could easily do so;
How would you get artifacts of a build done inside a Travis VM?
In any case, this still involves going through GitHub. Is anyone evaluating GitLab-CI https://about.gitlab.com/gitlab-ci/? Apparently their "runner" service can run on OSX (and Windows & Linux).
On Fri, Oct 2, 2015 at 1:20 PM, C. Scott Ananian <cananian@wikimedia.org
wrote:
On Fri, Oct 2, 2015 at 11:50 AM, Brian Gerstle <bgerstle@wikimedia.org
wrote:
Lastly, it appears that Travis's build-triggering API is still in
beta
http://docs.travis-ci.com/user/triggering-builds/, and there's no mention
of polling builds in this way.
I don't use this API, and it's not really suitable in any case. I just
use
the standard stable API for watching builds on a branch. Trigger is automatic with the push, which is a boring old git push, via the git
CLI.
If someone were to try using this with one
or more projects (e.g. Android) and decide to move forward, would we
reach
out to Travis to ask when the current API will be marked as stable or
if
they would be willing to work with us to develop an API more suited
to
our
needs?
Not sure exactly what that would be. The only oddity in the current
setup
is that I clean up the branch right after the build is complete -- but that's not an inherent property of the process. If we wanted to keep
build
artifacts around "forever", we could easily do so; I just wanted to
ensure
things were uncluttered in the github "branches" pulldown.
I'm all about doing what it takes to get the job done*, but just
wanted to be sure that were aware that this might not be the most
stable
way to use Travis.
There's nothing unusual about triggering travis builds by pushing to a branch.
The only thing that's interesting at all is that our branch names have slashes in them, and that issue was resolved a year ago: https://github.com/travis-ci/travis-api/pull/146
That property of our branch names was also optional; we used dashes
instead
of slashes as a workaround. But it does let us integrate better with
gerrit
access control mechanisms, which are built around slash-delimited
branch
names. --scott
-- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org