The generated documention for Parsoid does not properly display code blocks fenced with triple-backtick even though this is supported in the latest release of RDiscount (which jsduck uses to format markdown). JSDuck is verision 5.3.4, according to the generated documentation, so it is up to date. But RDiscount must be at 2.0.x, since fenced code block support appears to be missing. The latest version of RDiscount is 2.1.8. See: https://github.com/davidfstr/rdiscount/blob/master/CHANGELOG.md
Description
Description
Details
Details
Event Timeline
Comment Actions
We wanted to get a Debian package for JSDuck on Jessie (T95008). The packaging works involved ends up being rather painful so we gave up.
Instead we should have the Gem list defined in the software repositories. Then we can use bundler to grab them in the Jenkins job and execute whatever JSDuck version we want.
We have most of the logic existing already in JJB such as for yard (another ruby documentation tool):
- job-template:
name: '{name}-bundle-yard-publish'
node: contintLabsSlave && UbuntuTrusty
defaults: use-remoteonly-zuul
triggers:
- zuul
builders:
- bundle:
command: 'yard'
- doc-publish:
docsrc: 'doc'
docdest: 'rubygems/{name}'In short it runs:
bundle install bundle exec yard
Then assume the doc has been generated under /doc/ and rsync the content to doc.wikimedia.org
So we would need a bundle-jsduck-publish macro, craft Gemfile and then migrate existing jobs definitions in CI. Probably want to repurposes this task.
Comment Actions
@cscott mind if we change this task to Continuous-Integration-Config and retitle it to switch CI from jsduck deb package to a gemfile/bundler system?
Comment Actions
Change 280906 had a related patch set uploaded (by Hashar):
Have npm doc to install jsduck with bundler
Comment Actions
Change 280919 had a related patch set uploaded (by Hashar):
Pass BUNDLE_PATH to Nodepool jobs
This comment was removed by hashar.
Comment Actions
So repositories should get a Gemfile with jsduck and trigger the job rake-jessie
Alternatively, the npm entry point can be abused to run bundle install (still need a Gemfile) example https://gerrit.wikimedia.org/r/#/c/280906/1/package.json,cm
Comment Actions
I'd like to offer an alternative to adding a Gemfile everywhere.
Repositories should not have multiple test entry points or make files. Especially when these do not relate to the software in question. This is confusing to new contributors and complicates a lot of things.
First off, I agree we should not preinstall JSDuck on CI slaves. For the same reason that we don't preinstall Grunt or JSHint there. Preinstalling does not scale. It adds maintenance burden to CI administrators, and makes it very difficult to upgrade since it requires all jobs upgrade at once. Even if (which is a big if) all projects are to the upgrade, it's still impossible to orchestrate patches everywhere at the same time and then do the upgrade. Most dependencies belong either in the repository or in the job configuration.
These tools that should self-install as part of the test entry point. Or, if most contributors don't need to interact with it, it can be considered a prerequisite from the repo perspective and instead be installed as part of the job.
For the moment it seems clean and easy for everyone to simply run gem install jsduck as part of the relevant jobs.
In the future we can evaluate a way to store these snippets in the repository to simplify job configuration (e.g. similar to .travis.yml#before_install). But either way, we do not need and should not have a Gemfile just to install jsduck.
Comment Actions
Change 281627 had a related patch set uploaded (by Paladox):
Have npm doc to install jsduck with bundler
Comment Actions
Change 280937 had a related patch set uploaded (by Hashar):
Have npm doc to install jsduck with bundler
Comment Actions
Change 281937 had a related patch set uploaded (by Hashar):
Have npm doc to install jsduck with bundler
Comment Actions
Change 281938 had a related patch set uploaded (by Hashar):
Have npm doc to install jsduck with bundler
Comment Actions
@Krinkle +1
Adding bundle install jsduck to node's predoc target is emphatically *not* the right way to do this.
Comment Actions
With T136096 I have introduced a Jenkins job template that does roughly:
- gem install jsduck
- jsduck
While at it I have switched unicodejs, oojs/core and VisualEditor/VisualEditor. All passes.
Comment Actions
Change 290564 had a related patch set uploaded (by Paladox):
Add npm-run-doc-jsduck-node-4.3 test
Comment Actions
Given how jsduck is present in a wide range of jobs, I am just going to provision jsduck from ruby gems with something like:
package { 'jsduck': provider => 'gem', ensure => present, }
Comment Actions
Change 290704 had a related patch set uploaded (by Hashar):
dib: add jsduck to Nodepool instances
Comment Actions
Change 290708 had a related patch set uploaded (by Hashar):
dib: on Trusty set gem to gem2.0
Comment Actions
Change 290709 had a related patch set uploaded (by Hashar):
dib: install jsduck with a .deb package on Trusty
Comment Actions
Mentioned in SAL [2016-05-25T16:26:35Z] <hashar> 2016-05-25 16:24:35,491 INFO nodepool.image.build.wmflabs-eqiad.ci-trusty-wikimedia: Notice: /Stage[main]/Main/Package[ruby-jsduck]/ensure: ensure changed 'purged' to 'present' T109005
Comment Actions
Change 290564 abandoned by Hashar:
Add npm-run-doc-jsduck-node-4.3 test
Reason:
No more needed. jsduck is now installed on the Nodepool instances :-}
Comment Actions
Change 290928 had a related patch set uploaded (by Hashar):
jsduck-jessie no more install from rubygems
Comment Actions
Change 280906 abandoned by Hashar:
Have npm doc to install jsduck with bundler
Reason:
This was really just a short hack. Can revisit later if that is really needed.