Page MenuHomePhabricator

Create progressive disabled version of save button
Closed, ResolvedPublic

Event Timeline

Michael moved this task from To do to Doing on the Wikidata-Bridge-Sprint-7 board.
Michael added a project: User-Michael.

While working on this ticket a bug in @vue/test-utils was noticed and reported: https://github.com/vuejs/vue-test-utils/issues/1321
This bug could lead to falsely green tickets.

Change 543405 had a related patch set uploaded (by Michael Große; owner: Michael Große):
[mediawiki/extensions/Wikibase@master] bridge: Create progressive disabled version of save button

https://gerrit.wikimedia.org/r/543405

Change 543405 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: Create progressive disabled version of save button

https://gerrit.wikimedia.org/r/543405

Michael moved this task from Peer Review to Done on the Wikidata-Bridge-Sprint-7 board.

Shouldn’t this go into the Verification column for UX to review the button?

Michael moved this task from Done to Verification on the Wikidata-Bridge-Sprint-7 board.

Shouldn’t this go into the Verification column for UX to review the button?

So far my understanding was that mainly stories should go into verification, but moving this there makes sense as well.

However, I failed to get the hosted storybook to update :/

It seems there is some problem with not enough resources being available?

tools.wikibase-databridge-storybook@tools-sgebastion-07:~/Wikibase/client/data-bridge$ ./node_modules/@storybook/vue/bin/build.js -o ~/www/static
info @storybook/vue v5.1.11
info 
info clean outputDir..
info => Copying prebuild dll's..
info => Building manager..
info => Loading manager config..
info => Loading presets
info => Loading custom addons config.
info => Compiling manager..
info => manager built (1.02 min)
info => Building preview..
info => Loading preview config..
info => Loading presets
info => Loading custom webpack config (full-control mode).
info => Compiling preview..
Starting type checking service...
Using 1 worker with 2048MB memory limit
92% chunk asset optimization TerserPluginnode[23253]: pthread_create: Resource temporarily unavailable
node[23247]: pthread_create: Resource temporarily unavailable
/mnt/nfs/labstore-secondary-tools-project/wikibase-databridge-storybook/Wikibase/client/data-bridge/node_modules/worker-farm/lib/fork.js:23
  child.send({ owner: 'farm', module: forkModule })
        ^

TypeError: child.send is not a function
    at fork (/mnt/nfs/labstore-secondary-tools-project/wikibase-databridge-storybook/Wikibase/client/data-bridge/node_modules/worker-farm/lib/fork.js:23:9)
    at Farm.startChild (/mnt/nfs/labstore-secondary-tools-project/wikibase-databridge-storybook/Wikibase/client/data-bridge/node_modules/worker-farm/lib/farm.js:107:16)
    at Farm.processQueue (/mnt/nfs/labstore-secondary-tools-project/wikibase-databridge-storybook/Wikibase/client/data-bridge/node_modules/worker-farm/lib/farm.js:288:10)
    at Farm.receive (/mnt/nfs/labstore-secondary-tools-project/wikibase-databridge-storybook/Wikibase/client/data-bridge/node_modules/worker-farm/lib/farm.js:213:8)
    at Farm.<anonymous> (/mnt/nfs/labstore-secondary-tools-project/wikibase-databridge-storybook/Wikibase/client/data-bridge/node_modules/worker-farm/lib/farm.js:123:10)
    at emitTwo (events.js:126:13)
    at ChildProcess.emit (events.js:214:7)
    at emit (internal/child_process.js:772:12)
    at _combinedTickCallback (internal/process/next_tick.js:141:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)

The cause seems to be: node[23247]: pthread_create: Resource temporarily unavailable

Same problem here, I couldn’t get it to work (using jsub didn’t help either). For now I’d hope that it’s a temporary problem with Toolforge, and retry later?

Mentioned in SAL (#wikimedia-cloud) [2019-10-17T12:30:12Z] <Lucas_WMDE> $ npm run build-storybook && tar -C storybook-static -c . | ssh toolforge "sudo -i -u tools.wikibase-databridge-storybook sh -c 'rm -rf www/static/*; tar -C www/static/ -x'" # deploy locally built storybook (T235055)

@Lucas_Werkmeister_WMDE @Michael

According to the inspector the button seems to have a height of 36.7px. would that automatically adjust itself to 40px when placed in the header? Because that's the height it would need to have in the end.

@Lucas_Werkmeister_WMDE @Michael

According to the inspector the button seems to have a height of 36.7px. would that automatically adjust itself to 40px when placed in the header? Because that's the height it would need to have in the end.

Yeah, it will be the correct size in the header in a browser with a default font-size of 16.

coolio! then it all looks good \o/

I think so, yes (it would take on the full height of the header, as we already saw in T235622/T235623).

If we close this ticket, we can still add a note to the parent task to make the height part of its verification.