Libelektra: website: grunt fails on nodejs upgrade?
Is this an unsupported feature or I am doing something wrongly?
Describe what you wanted to do
add INI files as staticfile in structure.json.in
Describe what you expected
That INI files are rendered nicely with INI syntax highlighting.
Describe what actually happened
On the left side <!DOCTYPE html>, on the right side {{ 'APP.WEBSITE.LISTFILES.BUTTON.SHOWONGITHUB' | translate }}
System Information
- Elektra Version: master
Further Log Files and Output
markus2330
All 11 comments
Where did you try it? The structure.json part you posted contains a syntax error (missing curly braces on the empty line).
Namoshek
on 25 Jan 2017
Sorry, the diff is only partial, here the full diff:
diff --git a/src/tools/rest-frontend/resources/structure.json.in b/src/tools/rest-frontend/resources/structure.json.in
index 7613e0f..b524d4e 100644
--- a/src/tools/rest-frontend/resources/structure.json.in
+++ b/src/tools/rest-frontend/resources/structure.json.in
@@ -47,6 +47,13 @@
}
},
{
+ "name": "Metadata",
+ "type": "staticfile",
+ "options": {
+ "path": "doc/METADATA.ini"
+ }
+ },
+ {
"name": "Tutorials",
"type": "staticref",
"options": {
@@ -161,6 +168,20 @@
}
},
{
+ "name": "Contract",
+ "type": "staticfile",
+ "options": {
+ "path": "doc/CONTRACT.ini"
+ }
+ },
+ {
+ "name": "GSOC",
+ "type": "staticfile",
+ "options": {
+ "path": "doc/GSOC.md"
+ }
+ },
+ {
"name": "Version",
"type": "staticfile",
"options": {
EDIT: doc/GSOC.md is only available locally, but it is not related to the issue anyway.
markus2330
on 25 Jan 2017
It seems like the markdown parser creates the issue, but tracing is difficult (JS doesn't produce good error outputs). When I compile the file manually with this demo of the markdown parser though, it seems to work (note: the preparation tool adds the tripple ``` to the output, so its a code block).
I'll see if I find a quick fix, but I'm pretty busy right now.
Namoshek
on 25 Jan 2017
It's actually a very trivial issue (still very hard to track down) and it would probably not occur on the live version where we use apache with a configuration that does some sort of prevent this error. The problem is that the built-in development server of grunt needs a special configuration where we have to whitelist file extensions in order for the files to be served statically. In other words, adding 'ini' to the list of staticExtensions in the Gruntfile.js (line 265) will resolve the issue for you (please do the small change yourself).
Some more explanation:
Because of the missing staticExtension for ini (I added quite some extensions previously, but somehow I must have forgotten about ini), the server will respond with the index.html content instead of the requested file. The markdown parser ignores this (just passes it through because no markdown means nothing to do), but because we have internal links and stuff in our parsed documents, we also have to compile the resulting HTML in angular to make it work (this is done in the WebsiteListfilesController.js on lines 15-17). Doing this leads to recursion (because we loaded the whole website in the website, and that recursively).
Namoshek
on 25 Jan 2017
Thanks for finding out so quickly!
So the staticExtensions only refer to the frontend started by grunt? I will add ini, sounds like an easy job ;)
Do we really use the woff, eot, etc. files or are they only listed for completeness?
@e1528532 the discussion could be interesting for you to learn more about how the rest frontend works!
markus2330
on 25 Jan 2017
woff, eot, etc. are used by the font-awesome icons, imported through the vendor.css (created by grunt, so it is not in the source tree). Actually your browser may decide which font format it loads, as far as I know. So we need to list all of them.
Namoshek
on 25 Jan 2017
Thank you, it works perfect now! (see https://www.libelektra.org/docgettingstarted/metadata).
Unfortunately, a completely unrelated issue occurred (I hope it is okay for you to continue here in this thread). After a nodejs upgrade from v6.9.2 to v6.9.4 grunt fails (regardless of if 642161066fec9f4fe3c0a48af74b05a616c975dc is applied or not).
npm WARN [email protected] No repository field.
npm WARN [email protected] license should be a valid SPDX license expression
npm ERR! Linux 3.16.0-4-amd64
npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "install" "--unsafe-perm"
npm ERR! node v6.9.4
npm ERR! npm v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! [email protected] postinstall: `./node_modules/grunt-cli/bin/grunt install`
npm ERR! Exit status 3
npm ERR!
npm ERR! Failed at the [email protected] postinstall script './node_modules/grunt-cli/bin/grunt install'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the rest-frontend package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! ./node_modules/grunt-cli/bin/grunt install
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs rest-frontend
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls rest-frontend
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! /home/markus/Projekte/Elektra/installation/share/elektra/tool_data/rest-frontend/npm-debug.log
The issue seem to be introduced between nodejs v6.9.2 and v6.9.4. Downgrading is not so trivial (they only have the latest version in repo), thus I hold the website's nodejs package on v6.9.2 for now (I aborted upgrade when I noticed on my computer, luckily it was busy with upgrading other packages first..). So currently I only confirmed the issue on my computer and I thought I better leave the website until we know what the issue is (to avoid down time and stress). So if you cannot reproduce, please tell if you think upgrading nodejs on the website agent is safe.
markus2330
on 28 Jan 2017
I could reproduce the same issue on another computer: npm-debug.txt
Also clearing the npm cache did not help (rm -r ~/.npm. nor npm cache clear) and not even downgrading nodejs to v6.9.2 helped. (Even though the build server uses this version successfully.)
Any other ideas which caches could be involved?
markus2330
on 30 Jan 2017
I restored .npm, the build directory, and the installation directory from a backup (where Elektra had been 563134af2e6dd79f85000663a75d3b731f95cbd7 i.e. Tue Jan 24 16:34:50 2017) and everything works again.
Would be still interesting what caused the issue and how to avoid it and why rebuilding Elektra, cleaning .npm, and removing the installation directory did not help. Is there some relevant information of the frontend within the CMakeCache?
markus2330
on 2 Feb 2017
Hm, I cannot reproduce the issue locally.
$> node -v
v6.9.4
$> npm -v
3.10.10
$> kdb configure-rest-frontend
Running "less:build" (less) task
>> 1 stylesheet created.
Running "cssmin:build" (cssmin) task
>> 1 file created. 60.13 kB → 46.37 kB
Running "concat:vendor" (concat) task
Running "concat:pacejs" (concat) task
Running "concat:pacecss" (concat) task
Running "create-website-news:build" (create-website-news) task
>> News post 2014-10-22_augeas.md has no short description matching the configured regex!
>> Website news file generated successfully!
Running "create-website-news-rss:build" (create-website-news-rss) task
>> News post undefined has no guid that can be used to generate an RSS post!
>> News post undefined has no guid that can be used to generate an RSS post!
>> Website RSS news generated successfully!
Running "create-website-structure:build" (create-website-structure) task
>> Website structure file generated successfully!
Running "copy-website-content:build" (copy-website-content) task
>> Website content copied to target directory successfully!
Running "copy:build" (copy) task
Copied 4 files
Running "create-website-sitemap:build" (create-website-sitemap) task
Running "preprocess:config" (preprocess) task
Running "preprocess:index" (preprocess) task
Running "browserify:build" (browserify) task
>> Bundle resources/application.js.tmp created.
Running "uglify:build" (uglify) task
>> 1 sourcemap created.
>> 1 file created.
Done.
Maybe deleting the node_modules directory in /usr/local/share/elektra/tool_data/rest-frontend solves the issue. It is also possible that there is an error in one of the scripts, but somehow I doubt that because there were no drastic changes in between this node versions.
You can by the way manage different node versions quite easily with the tool n.
npm cache clean -f # clear the npm cache before installing n to get the latest version
npm install -g n # install n as global utility
n stable # installs and enables the latest stable node version
n latest # installs and enables the very latest node version
n 6.9.2 # installs and enables node version 6.9.2
n 6.9.4 # install and enables node version 6.9.4
n 6.9.2 # only enables node version 6.9.2 because it is available already
n # lists all installed node versions and allows to select one to be used
It is possible that the enabled node version is only shown after using a new terminal (not sure how it is on a server over ssh).
Namoshek
on 4 Feb 2017
Ok, thank you for investigating! Will try to clean up node_modules next time. Hopefully, this problem never occurs on the build server!
markus2330
on 4 Feb 2017
Related issues
markus2330
·
4Comments
mpranj
·
3Comments
e1528532
·
4Comments
dominicjaeger
·
3Comments
markus2330
·
4Comments