Add a property to the 'tags' object in the /user/{name}/contributions
REST endpoint named 'display' which shows the display
HTML for the tag which is either defined in i18n .json
files or overriden at MediaWiki:tag-$name
Bug: T259716
Depends-On: I57e2a7253944a3fde3f52f52bbf5fe8473c8a415
Change-Id: Id755adcab8b0115e19df2a6046643ebe97881e28
The endpoint for user contributions should include change tags in the
result. Bump the version of npm module api-testing.
Bug: T252202
Change-Id: Iccc0c378bc65d0f34b38557f4c78f424d95a951f
Earlier versions of WebdriverIO lacked support for video recording.
Starting with WebdriverIO v5, a new package wdio-video-reporter
has been introduced which is used to replace ffmpeg and Xvfb.
Limitations:
- Alert messages and pop-ups do not get displayed in the videos.
New Packages:
- wdio-video-reporter
Bug: T255253
Change-Id: Id443779959bfac55eae42e16e10d1f20c25375bb
This is part of a chain of patches to complete the REST User Contributions
endpoint. This change returns a list of the 2 (hard-coded for now) most
recent revisions for a given user.
Package.json was also updated for new api-testing module (v 1.1.0)
Bug: T252202
Change-Id: I42a5dfc0e1ff7600848e89ac2c4b002e8a3612df
This reverts commit babbbbc6e5.
Reason for revert: Video recording only works with WebdriverIO v5. It doesn't work with v6.
Bug: T252523
Change-Id: I5dd0bb5ef03bcf5337207c63d26755e983634787
Earlier versions of WebdriverIO lacked support for video recording.
Starting with WebdriverIO v5, a new package wdio-video-reporter
has been introduced which is used to replace ffmpeg and Xvfb.
Limitations:
- Alert messages and pop-ups do not get displayed in the videos.
Bug: T252523
Change-Id: I6c964467066eb30e28a3435ddf7831a4e296b8f5
Was first attempted in f1eaa06d5e,
and reverted in 0b3fe4fe8c. Now this
is done in eslint-config-wikimedia for all repos.
Change-Id: I9ee735eef40085b6373b565838d67e186e438657
This reverts commit f1eaa06d5e.
Reason for revert: accidentally allowed ES6 syntax.
Looking for a way to redo this that doesn't break our linting as badly.
Change-Id: I78974b97001bdbea9aff5717c69d71b8a2582ade
Whether JSDuck or JSDoc3, it's good to verify that there are no
regressions in the doc syntax. This has been enforced by WMF CI
for many years with a dedicated Jenkins job.
However, both 'grunt lint' and 'npm run doc' take a relatively
small amount of time in CI:
* grunt lint: ~ 35s (not incl 'npm install')
* npm run doc: ~ 10s (not incl 'npm install')
Bug: T225730
Change-Id: If22b7bc64266e43088c7dec8138d81c938687fb9
47cc31d changed running selenium.sh using sh instead of bash. This
commit reverts back to bash, since sh does not support pipefail.
Bug: T247983
Change-Id: Ia2706051d40a6c26156fef77744cf5dff3a8cf95
Run the script explictly via sh, the default is cmd.exe on Windows.
Also ported from bash to sh per Jforrester's request.
Change-Id: I96b66c6ae01a1761619955be2e8a3dbc64edff18
Follows-up 7d9e117d91, which added this for use in WikibaseMediaInfo,
which should have been added there instead of here.
This has since been fixed.
Change-Id: I6d5b0c93c3de457da0bf54859f05b1836eccc84f
Install eslint-plugin-vue, which lints JS inside <script> blocks in
.vue files, and also lints Vue templates. Configure eslint and stylelint
to run on .vue files. stylelint automatically picks up on CSS in <style>
tags.
You may have to change a setting in your text editor or IDE to make it
run eslint and stylelint in .vue files. For eslint, see
https://eslint.vuejs.org/user-guide/#editor-integrations ; for
stylelint, I had to install the linter-stylelint-plus Atom plugin then
add source.css.embedded.html to the "Base Scopes" setting for that
plugin.
Change-Id: I7e6a13317792fc25c29106739b0c24864fd8d301
This package was serving two purposes:
* Install chromedriver automatically.
* Start chromedriver automatically when using the
'npm run selenium' entry point (e.g. for local development).
For the CI entry points (selenium-test, selenium-daily) the
chromedriver is skipped. For those, we expect the CI runner to
have started a chromedriver server already, which allows the
server to continue running between different the test suites
of different extensions etc.
By letting WDIO start the chromedriver for local development,
we had the benefit of 'npm run selenium' directly being an alias
to the 'wdio' command. This made it easy to pass additional
arguments like --spec or --mochaOpts for running specific tests
only and overall makes things easier to reason about from a
developer perspective with fewer (required) layers of
indirection you see and need to understand when debugging.
But, this has also caused problems. Specifically, it means
developers have to use the same version of Chrome locally
as we specify in package.json which isn't very flexible. While
we could try to keep this up-to-date roughly, that too isn't
an option because the secure environments we recommend for local
use (Quibble and Fresh-node) both use a Debian distro with
typically older versions of Chromium than your local auto-updating
Google Chrome.
For now, let's go back to moving the responsibility of installing
chromedriver together with the responsibility to install Chrome
itself.
== Changes ==
For CI, nothing changes (it already installs both).
For developers using Quibble, Vagrant or Fresh nothing changes
(already installs both).
For developers who make their own secure environment, they will
need to make sure chromedriver is installed, just as we required
between 2017 and Aug 2019 before my commit 1955a8aa56.
== How ==
wdio-chromedriver cannot start a foreign install because the
protocol can change between versions, so unfortunately together
with not using chromedriver from npm, we also can't use
the wdio-chromedriver autostart mechanism. Instead, I'm bringing
back Antoine's shell script that did this prior to ebda397c54.
But, with a few tweaks so that it forwards shell arguments,
this way developers continue to enjoy the benefit of 1955a8aa56,
which is that 'npm run selenium -- --spec foo.js' works.
Bug: T234610
Change-Id: I03ca94315d0611d2b6abccc12cf9076d41b2c00e
* Options no longer needed or no longer exist in wdio v5:
- coloredLogs: Now always on. The underlying 'chalk' library can still
be influenced via the FORCE_COLOR environment variable.
- screenshotPath: Removed. Was already disabled in our config.
- deprecationWarnings: Meh.
- 'sync: true' – On by default when `@wdio/sync` is installed.
The wdio v5 config generator doesn't recommend setting manually.
* The selenium.sh script was removed. It existed to start and stop
chromedriver for local use by developers. This is now done by
the wdio-chromedriver-service. In WMF CI, Quibble starts its own
chromedriver (as optimisation, reused across gated repos),
which is why the 'selenium-test' entry points remains and skips
this.
* The wdio-mediawiki package now requires wdio v5 and Node 10.
This doesn't affect extension repos because versions are pinned.
Upgrade may happen at the earliest convenience.
* Several WDIO methods changed names or signature. Full list at:
<https://github.com/webdriverio/webdriverio/blob/v5.13.2/CHANGELOG.md#v500-2018-12-20>
Highlights:
- browser.element() is now browser.findElement() with "$()" as alias.
- browser.localStorage replaced by browser.setLocalStorage.
- browser.deleteCookie() requires `name` param. To delete all at once,
there is a new method browser.deleteAllCookies().
- Commands that return data no longer wrapped in `{ value: … }`.
Values are now returned directly.
- Custom config keys are now under browser.config instead of browser.options.
Renamed our username/password keys to be mw-prefixed, to avoid clashes
and reduce confusion with similar config keys.
- browser.click(selector) and browser.getText(selector) no longer exist.
Use $(selector).click() or .getText() instead.
* Fix "no such alert" warning from specs/page.js by removing the apparently
redundant code.
Bug: T234002
Bug: T213268
Change-Id: I908997569ca8457997af30cb29e98ac41fae3b64
Updating packages removes dependency on cryptiles. We were using
version 3.1.4 that had a vulnerability.
Bug: T226586
Change-Id: Idccc7f418ed6fce7452a6f0d403477953448a541
This reverts commit c3878c08b5.
Now that we're running on node10, this will fail until we fix
things.
Bug: T213268
Bug: T222406
Change-Id: I5935fc5d5bc23978e50275d3c99ac870b3b82f49
This is so that we can migrate to node 10 in CI. It should only land
for an hour or so, and is to be reverted as soon as we get CI up to
node 10 and working, lest our suites of selenium tests become
subject to bitrot.
Bug: T222406
Change-Id: I9473e0213c070a0e963913fd81062c6bbf9ec2f2
`npm install` currently fails due to an unsatisfied peer dependency.
See full output here:
https://phabricator.wikimedia.org/P8552
Bumping the required grunt-karma version to the latest (3.0.2) fixes
this.
Change-Id: I5b7f2deba2d766b809a964f53cb22f47f0617bd6
It is needed for I92739d84947ac146e in WikibaseMediaInfo Selenium tests.
It can not be added there because of T199116.
Bug: T219815
Bug: T199116
Change-Id: Ib7c3b1b49c280bdc38c40c6aef900a605c1e3cbe
Also:
* Remove "watch" task from Gruntfile.
This wasn't exposed via npm-run and afaik rarely if ever used.
It seems mostly obsoleted by modern editors which perform
linting and style guidance as-you-type and on-save.
* Remove "chromium" target from karma config, the default
target supports both Chromium and Chrome.
* Remove unused "default" alias in Gruntfile. Was only
accessible if developers installed grunt-cli globally, which
we don't require and shouldn't encourage. The new minify task
is now exposed as "npm run build".
* Remove "test" alias in Gruntfile. Was only used by "npm run test",
which now uses "grunt lint" directly, which makes it more clear
that these are only linters, and not unit tests.
This references T211784 because ensuring no headed browsers are used
(which would need Xvfb to start), is a prerequisite for the new Node 10
images. We may still need to provide a slower Xvfb-wrapped variant for
some repos, but would be nice of mw-core wasn't one of them.
Bug: T211784
Change-Id: I270a16d2b4f799ac7c9f84e9e2ee23806bdbc57e
This fixes the bug where HeadlessChrome was always shown as
version 0.0.0 in the console output, which makes it rather
difficult to debug which Chrome version is installed.
Upstream https://github.com/karma-runner/karma/issues/2762,
which updates the ua-parser library to a version that fixes
that bug.
Change-Id: I0b7fe7f8a90649592c4d31fb3055cdc9e8d34814
Adding 'grunt-svgmin' package and corresponding 'svgmin' task and
also crush SVGs. Several of them are featuring bad UX and are not optimal
in many different angles (a.o. clarity, universality, recognizablity etc.).
Specifically the 'mediawiki.skinning' ones.
But while they are here, let's make them suck less.
Change-Id: I8191ceac14565ae31d941982fab1586fa9b6bbdd
Was added for wdio-related code, but not used in the end.
The only reference to this module anywhere in Wikimedia Git is
mediawiki/extensions/CirrusSearch, which doesn't use it for
its regular or daily tests, but rather the integration test,
which already has its own copy of this module in package.json.
Change-Id: Ifdf4362077f4684a2866363e35d0aca2f89f48b5
Code and integrity from <https://code.jquery.com/qunit/>.
Release notes at <https://github.com/qunitjs/qunit/releases>.
Highlights for the browser version:
- [2.7.0] Reporter: Remove cost of DOM size when
using "hidepassed=true".
- [2.7.0] Reporter: Use perf.now() for improved accurracy
of unit test durations.
- [2.7.0] Reporter: Make debugging tests in a browser
easier by adding timeline markers for DevTools.
Highlights for the npm package / CLI version:
- [2.9.0] CLI: Reduce dependency tree size
from 143 packages to 9 packages.
Change-Id: I38408d90765cd18d5dd6952b8b6b30cbfa0c7ed5
Selenium tests run fine when targeting MediaWiki installation in
MediaWiki-Vagrant and in Jenkins, but fail when targeting beta cluster.
Until tests are refactored to run without failure for beta cluster, let's disable
failing tests.
Bug: T185011
Change-Id: I12da893e7d624d4ebe478bccf0706aa07c965796
selenium-daily just calls selenium-test. It's needed for daily Jenkins job targeting
beta cluster. The script might seem redundant, but it provides flexibility. In case
a repository does not want to run all tests daily, that's easily fixed by updating
the the script.
Bug: T188742
Change-Id: Idf86f94cc31abda4bfcdc1ac4eba29206d9c91f9
This is new package will be reusable by other repositories for
their browser tests, without having to reference the internal
selenium/pageobjects/ directory from MediaWiki core.
In addition to not requiring direct imports, it will also avoid
problems in the future by allowing the package to be versioned
and iterated upon without forcing an atomic global upgrade
(or broken master builds), everytime we change something.
See wdio-mediawiki/README for details.
Within MediaWiki core itself, the package is used using the
'file' specifier in its package.json, so that we always test
and develop using its working copy, which makes drafting and
testing changes easier.
Also misc changes to make wdio.conf easier to understand.
Bug: T193088
Change-Id: I547a7899e7a97693a93567dd763784e637433d55
This is functionally a no-op, purely refactoring (mostly style).
* Consistently require packages at the top of a file.
(e.g. MWBot in edit.page.js).
* Remove unused .call(this) from mwbot interaction closures,
which didn't use 'this'.
* Use Node.js regular Promise chaining with then(), instead of
complex bluebird.coroutine generator function yields, which
are intended to emulate async-await, but the syntax is quite
error-prone for inexperienced developers and hard to debug.
Once we require Node 7+ for the selenium tests, we can use
async-await here natively, but until then, might as well use
regular then() syntax, which we already use elsewhere in the
tests, and is also what MWBot documentation uses.
* Also applied some minor whitespace changes for consistency
among these files and other MediaWiki JS. E.g. no empty line
before the first statement of a function. Add a new line between
different methods, and between the end of a class and the
export statement.
* Remove 'use strict' from test files. The patterns that would expose
the bad non-strict behaviour are mostly already forbidden by ESLint,
and the run-time optimisation to disable non-strict can't be noticed
in tests (more useful in prod where e.g. the same process would run
a function 1 million times). Main reason here is to keep things
simple for new-comers and reduce boilerplate, given that these tests
will mainly be worked on by browser-JS developers, not Node.js devs,
and we don't currently use strict mode in our front-end code, either.
* Remove unused bluebird dependency.
Bug: T193088
Change-Id: I59f9211299e8e884c28c7733bcee3b7b28542610
Doesn't seem to add anything, except complexity.
This has the benefit of matching more closely the way the README
recommends running individual tests.
Also add a check for 'chromedriver' before running it.
Normally the -e and pipefail would suffice, but because
it runs in the background, the error can be buried,
hard to find, or even not cause exit code to be set
properly. Thus, do a simple 'hash' check that will
print a useful command and exit cleanly.
Before:
> $ something &
> [1] 57922
> -bash: something: command not found
> [1]+ Exit 127 something
> $ echo $?
> 0
After:
> $ hash something
> -bash: hash: something: not found
> (exit: 1) $ echo $?
> 1
Change-Id: Id95f18927b5443defe679a77a82c5cbdd127c716
This makes it possible to use in Quibble. Right now, Quibble
cannot use 'npm run selenium' yet because it sets up its own
chromedriver, which would conflict with selenium.sh.
But, in preparation for Id95f18927b5, we can at least abstract
the test command so that it can easily be changed without having
to update Quibble and without having to worry about it being the
same in all MediaWiki branches.
Bug: T179190
Change-Id: I622ec3bf36746502cae891cc6bec23982b21f876
Just running `npm run selenium` in CI does not work. If WebdriverIO fails, the
job still passes since the last command to run is `killall chromedriver`.
Reusing the script from CI that starts and stops Chromedriver should fix the
problem.
Bug: T179190
Change-Id: If29227263d23a3e4f26e2329dfa13c49f976cf8e
Bluebird is implicitly installed on my machine, probably because I have a recent npm version. It needs to be explicitly installed in MediaWiki-Vagrant, probably because of an older npm version.
Bug: T190914
Change-Id: I9c704502fb5e20abf9b21d483723eb55b6fb3875
The running of 'grunt qunit' is unconvenient due to it only working
if the user has grunt-cli installed globally, which should not be
needed because it is already installed in the local directory.
It could be worked around by instructing users to use
`./node_modules/.bin/grunt qunit`, but it would be much simpler
to instruct them to use `npm run qunit` instead.
Unlike 'composer', 'npm' does not come by default with a command
like 'composer exec' that one could pass a command directly
without needing to register it. This is fixed in more recent
versions through 'npx -c', but that's a bit too new to require
in the manual, so adding it as a run-script instead.
Change-Id: I2812b13dbed50612b1626a617ba65f92e212f01a
Special:JavaScriptTest loads qunitjs from /resources/lib/qunitjs
which was upgraded in 99aad9397e to 1.23.1.
However, when running QUnit tests from the command-line, QUnit is
loaded by karma-qunit using the npm qunitjs dependency, which was
still at v1.22.0.
Change-Id: Ie24b2b061735fa03a8ed1527d09f65c103506c67
The progress reporter is quite nice to avoid spammy output to the
terminal, but it is not very human friendly when trying to find out what
is breaking.
Mocha has a very nice reporting organized as modules and list items for
each of the tests:
ext.cx.tools.template
✖ Equivalent template exists
✔ Adapting a template not existing in target language
✖ Adapting template having invalid title
✖ Template name and params adaptation using templatedata
✖ Template params adaptation using templateData - English to French
✖ Template params adaptation using templateData - English to Spanish
Add karma-mocha-reporter node module and make it the reporter.
Change-Id: Ic7d848b45e8e5ad3839d8a2bd822b63838319ad7
Introduce the WebdriverIO browser testing framework driven by Node.js.
The overall intents are:
* have MediaWiki core to provide a platform to run tests that is shared
between core and the extensions.
* phase out ruby driven browser tests eventually.
Code is namespaced in sub directory /tests/selenium
The 'pages' sub directory provides helper representing a MediaWiki page
such as Special:Login and human friendly helpers to interact with the
elements.
Add Grunt task webdriver:test.
Provide a npm script to easily spawn/dispose chromedriver and run above
grunt task.
wdio.conf.js provides all the configuration. It defaults to point to a
MediaWiki-Vagrant installation on http://127.0.0.1:8080. Can be
overriden with environment settings as needed.
glob patterns (specs) are made absolute paths from MediaWiki root path
that let us run the tests either from the root path (eg the npm
wrapper or from the tests/selenium directory when invoking wdio
directly. wdio assumes they are relative to the current working
directory, hence the normalization.
wdio.conf.jenkins.js extends the configuration and is used solely for
Jenkins. The switch is done from the Gruntfile.js whenever JENKINS_HOME
is set. Specially we want junit reports to be generated.
Provide a more specific eslint configuration.
References:
* MALU https://phabricator.wikimedia.org/source/malu/
* T151442 Research WebdriverIO
* T151443 Research Nightwatch.js
Bug: T139740
Signed-off-by: Antoine Musso <hashar@free.fr>
Change-Id: Ibe7a004a120e82af637ab3e31b725de743134c99
Before karma-chrome-launcher 2.0.0, Chromium was only detected on Linux
and as part of the "Chrome" setting. "Chromium" is now recognised as a
separate browser and is detected on Mac and Windows as well.
https://github.com/karma-runner/karma-chrome-launcher/issues/45
Add a grunt target for Chromium so users may run the following to use
Chromium instead of Chrome:
grunt karma:chromium
Since we keep the default of "Chrome", we'll need an override for CI
since we install Chromium there instead of Chrome.
Depends on Ie9f906f8 being merged and Nodepool images updated.
Bug: T153756
Change-Id: I6ba0d971e7e8c3022d2ab6268ae637688189d768
We don't want tests failing every time upstream publishing a new
version.
Instead we should bump this manually everytime they update to make sure
no failures happen.
Bug: T118941
Change-Id: I1c76dacd0950100825b85a3791f74c1f6d5477d9
Karma is suspected to have an issue disconnecting Chromium.
That causes the qunit job to idle even after all tests have
been completed.
This reverts commit 72b0d9da08.
Bug: T136188
Change-Id: Id818f5a0d1983d0bffa545f7731a780bf2b9bf25
Initially, with just a single rule to make this a smaller change that we can
incrementally extend up to the full Wikimedia coding conventions preset; namely,
forcing hex references to colours to be in lower-case.
Note the odd src definition to avoid referring to mediawiki.less the directory in
the glob.
Change-Id: I34f0c8e3c8280e3fce0aa22d7537100b850cbb8d
Reason because this update will include a fix for incompatibility with
grunt 1.0.0 when it is released.
Change-Id: I39f01e3a68b764a4638c3465a1d116aefd517ef5
Taking the opportunity to modernise our .jshintrc file, I have made the
following changes there and adjusted the repo to pass:
* Replaced the deprecated `"es3": true` with `"esversion": 3`; nil change.
* Adjusted `"latedef": true` to `"latedef": "nofunc"`, a new setting for this
option that lets us retain previous behaviour. One call needed to be adjusted
for the update with this change; without it, several dozen were needed.
* Added `"futurehostile": true`, to make bumping `esversion` easier in future.
I have reviewed the rest of the options and chosen not to apply them:
* No need to over-ride the runtime option `maxerr`.
* No need to add the additional 'enforcing' options: `forin`, `nocomma`,
`nonbsp`, `notypeof`, `predef`, `shadow`, `singleGroups`, `varstmt`.
* No need to add the additional 'relaxing' options, as ideally we should use
none: `asi`, `boss`, `debug`, `elision`, `eqnull`, `evil`, `expr`,
`lastsemic`, `loopfunc`, `moz`, `noyield`, `plusplus`, `proto`, `scripturl`,
`supernew`, `validthis`, `withstmt`
* Definitely no need to add any of the deprecated coding style-related items:
`camelcase`, `curly`, `immed`, `indent`, `laxcomma`, `maxlen`,
`maxcomplexity`, `maxdepth`, `maxparams`, `maxstatements`, `newcap`,
`noempty`, `quotmark`, `sub`
Note that we retain two deprecated options, `laxbreak` and `multistr` which are
set to be removed in the next major version of jshint but are as-yet required
for the repo so that it passes.
Change-Id: I2a780f655010f2231ab2ab93c40b34943828b4df
This update now tells you on which line in which file the error happends.
Changelog is
1.0.7 Include file name and JSON source line number in error messages
1.0.6 CJSON support thanks to @fredghosn, unit tests
Change-Id: I38dc4a51416cfde0bb0434921d15f1c119abc01b
2.5.0
Bump JSCS version to 2.7.0
2.4.0
Bump JSCS version to 2.6.0
2.3.0
Bump JSCS version to 2.5.0
2.2.0
* Update jscs dependency to 2.4.0
* Use new Checker#execute method, which allows to respect maxErrors
* option when fix option is enabled
* fix option is now directly passed to Checker class of jscs
* Use new "idiomatic" preset instead of "jquery"
* Test in latest version of node in travis CI
* Update dev dependencies
https://github.com/jscs-dev/grunt-jscs/releases
Change-Id: I472a3c63fff814357799a3889b09bbb6a977474b
This fixes the warning about missing package description and license.
This matches what we do elsewhere for dev-only npm pipelines.
Change-Id: I29ee43482b90ea8875a5376409d656648e3c4b27
Disable disallowBlankTranslations, disallowDuplicateTranslations and
disallowUnusedTranslations for now as they fail so much.
Change-Id: I52e1555335a6e64b1e9db541ba726cf6ce8c7dd0
A long time ago, npm did not support using command line programs
within 'npm test' (not unless harcoding a path to node_modules/bin/...
within packages.json/scripts/test). But this has been long supported.
Declaring a (dev)dependency will provide its binaries to the
PATH used by the subshell 'npm test' creates internally.
Add grunt-cli so that developers don't have to manually install it.
Change-Id: I6a7fafa3c6e40d2407f07c514167ab9fc7661685
* Move configuration to /jsduck.json per standard. This way
it can be run as plain '$ jsduck' without needing a maintenance
script or custom Jenkins job. Similar to JSHint, JSCS, Grunt,
and Gem etc.
* Move --processes=0 from maintenace script into config file.
This should've been in the config file all along and serves as
workaround for https://github.com/senchalabs/jsduck/issues/525.
* Use grunt-contrib-copy instead of a symlink for resources.
For local development a symlink works fine, but for publishing
from Jenkins to doc.wikimedia.org the /docs/js/ directory needs
to be standalone. This was previously done with a manual post-build
step that added an additional rsync, but this logic should be
in the repository so that the doc entry point can be simplified
and standardised to 'npm run-script doc' for all projects.
Change-Id: Iaaaac50ee78dd9ff8f24f1ef3a3685ad51cf33b2
This is way overdue as it isn't experimental anymore.
Keeping it in a non-standard subdirectory makes it harder to
discover for people. And makes it harder to run from Jenkins
since this is already being ran on every commit.
Related to 70f3919.
Change-Id: Iaf5cf65616f82640145fbb6395c36129428602ca
