Hugo stage of gulp process causing 'Command failed' error

[seffw]

I tried this (Windows 7 x64) but could not get gulp to complete the build script.

It fails when the hugo command is run.

What makes it super confusing (I'm also new to gulp) is that the hugo project is called hugo (so it's hard to know what refers to hugo and what to the project).

Also I don't know if this is a gulp thing, but there are layers of dependency which make modifying it hard. If this is how gulp works, its not for me.

Example: reference:all links to hugo:all and build:all looks for reference:all. I tried to remove the hugo part of the gulp process but it got messy.

Personally I think running Hugo from within the gulp file is unnecessary, and better to enable the user to run the command they want foor that project at whatever stage.

[jbrodriguez]

hi @simplyeffectiveweb, is the error similar to this ?

'hugo:all' errored after 1.24 ms
TypeError: undefined is not a function
    at hugo (/[path]/gulp/hugo.js:18:18)
    at Gulp.<anonymous> (/[path]/gulp/hugo.js:27:5)
    at module.exports (/[path]/node_modules/gulp/node_modules/orchestrator/lib/runTask.js:34:7)
    at Gulp.Orchestrator._runTask (/[path]/node_modules/gulp/node_modules/orchestrator/index.js:273:3)
    at Gulp.Orchestrator._runStep (/[path]/node_modules/gulp/node_modules/orchestrator/index.js:214:10)
    at /[path]/node_modules/gulp/node_modules/orchestrator/index.js:279:18
    at finish (/[path]/node_modules/gulp/node_modules/orchestrator/lib/runTask.js:21:8)
    at /[path]/node_modules/gulp/node_modules/orchestrator/lib/runTask.js:52:4
    at f (/[path]/node_modules/gulp/node_modules/orchestrator/node_modules/end-of-stream/node_modules/once/once.js:17:25)
    at DestroyableTransform.onend (/[path]/node_modules/gulp/node_modules/orchestrator/node_modules/end-of-stream/index.js:31:18)

I'm thinking you probably have an outdated version of node, similar to issue #5

I'm not sure what you mean with the project being called hugo.

Do you mean the folder or the task ?

With regards to the layers of dependencies, this is how gulpjs 3.x works.

It's like a cascade ...

• you want to run build:all, ok but it depends on reference:all so it executes that task first
• reference:all depends on hugo:all, so hugo:all is run
• hugo:all depends on revision, so revision is run first.

That's the way it works.

[seffw]

Pretty sure Node is the current version. Will check that.

Here is the error (I should have posted this before, sorry)

[21:59:14] Starting 'hugo:all'... [21:59:14] src: C:\Users\Main\hugo\hugo dst: C:\Users\Main\hugo\public [21:59:14] 'hugo:all' errored after 82 ms [21:59:14] Error: Command failed: hugo --buildDrafts=true at checkExecSyncError (child_process.js:441:13) at execSync (child_process.js:481:13) at hugo (C:\Users\Main\hugo\gulp\hugo.js:18:18) at Gulp. (C:\Users\Main\hugo\gulp\hugo.js:27:5)

Note: in the 4th line this is after editing the hugo.js file to simplify the hugo command. In you original file it produced:

[11:47:22] Error: Command failed: hugo --config=hugo_gulp/config.yaml -s C:\Users\Mike\hugo\hugo_gulp -d C:\Users\Mike\hugo\public --buildDrafts=true --verbose=true --baseUrl="http://localhost:3000/"

But the error is exactly the same.

About the name of the project, yes I mean the folder. For example, for me the normal structure (Windows) might be:

Main --hugo -----hugo_site1 -----hugo_site2

with the hugo main area and the sub folders of hugo sites. So for yours I have:

Main --hugo -----hugo

I appreciate it want matter from a folder point of view, it just means i the code there is references to hugo (the program)) and hugo (the folder).

I also tried runnning the gulp command from the main hugo folder and the hugo sub folder, and the result / error is the same.

Thanks for info about gulp. Perhaps ultimately I need to look for a more linear build tool.

[jbrodriguez]

It's not immediately obvious to me what the error might be.

Try running hugo from the command line

$ hugo --config=hugo_gulp/config.yaml -s C:\Users\Mike\hugo\hugo_gulp -d C:\Users\Mike\hugo\public --buildDrafts=true --verbose=true --baseUrl="http://localhost:3000/"

It should provide a better error message.

As for the folders, I see what you mean.

You could always change it to something like

Main -- website ------hugo

:)

[seffw]

That hugo command and the original (before I started to change the folder name and code related to it) did not work as a regular hugo command. But I don't think that is the issue.

Putting a simple hugo command in it's plan, which does work in command line for hugo, produces the same error here.

I think the way it tries to run hugo doesn't work, and I think the solution is to remove the hugo call, and run that as a separate process. I tried to do this, but i couldn't get past the dependency bit, and I don't know gulp.

Anyway way this could be done?

Regarding the folder names, I didnn't mean about renaming my own setup. I mean that in your hugolp files, because you've got the project name as hugo also, it makes understand the code more difficult (as I was not sure which relates to Hugo (program) and which relates to hugo (your project folder).

[jbrodriguez]

That hugo command and the original (before I started to change the folder name and code related to it) did not work as a regular hugo command. But I don't think that is the issue.

I think this is relevant.

If the code as called from within gulp, doesn't work when called from the command line, then it's not a gulp issue, it would seem it's more of a setup issue.

Could you

$ c:
$ cd \Users\Mike\hugo
$ hugo --config=hugo_gulp/config.yaml -s C:\Users\Mike\hugo\hugo_gulp -d C:\Users\Mike\hugo\public --buildDrafts=true --verbose=true --baseUrl="http://localhost:3000/"

and paste the result here ?

With regards to running hugo separately, it's currently not possible as hugo needs to populate the content, before all the referencing, revisioning, etc. takes place.

[seffw]

I think there is a bit of miscommunication, probably I haven't explained very well.

In the hugo.js file, I tries all sorts of hugo commands. Some worked (i tested directly in Hugo), the one produced before my changes did not. But I think it's irrelevant because all produced the same error (regardless of whether the command worked in hugo or not).

Here is the result you asked for (with some changes I needed to make to the command to make it work with the current setup). This command also produces the error when run from the gulp script.

C:\Users\Mike\hugo\hugo>hugo --config=config.toml -s C:\Users\Mike\hugo\hugo -d C:\Users\Mike\hugo\public --buildDrafts=true --ver bose=true --baseUrl="http://localhost:3000/" INFO: 2015/09/30 Using config file: config.toml INFO: 2015/09/30 syncing from C:\Users\Mike\hugo\hugo\static/ to C:\Users\Mike\hugo\public/ WARN: 2015/09/30 Unable to locate layout for homepage: [index.html _default/list.html] WARN: 2015/09/30 Unable to locate layout for 404 page: [404.html] 0 draft content 0 future content 0 pages created 0 paginator pages created 0 tags created 0 categories created in 19 ms

Don't worry if this is going to take too much time. I think anyway I'd be better off looking for a way to do this as a separate process. As there are two distinct processes (pre-processing and minifying) and then the website build, with each potentially having separate errors, it's better for me to run them separately.

[seffw]

An update.

I've got it working I think. I made a few changes as well to make it more adaptable over multiple projects.

I've changed the public folder to be within the individual project (as per normal hugo)

This is the new part of hugo.js (projectpath is defined in build.js):

var src = path.join(process.cwd(), projectpath);
var dst = path.join(process.cwd(), projectpath + '/public');

gutil.log('src: ' + src + ' dst: ' + dst + ' path: ' + projectpath);

var cmd = 'hugo --config=' + projectpath + '/config.yaml -s ' + src + ' -d ' + dst;
 cmd += ' --theme=../../themes/casper';
if (drafts) {
    cmd += ' --buildDrafts=true --verbose=true --baseUrl="http://localhost:3000/" ';
}

I added theme here because it did not seem to work when in the config file in this case.

EDIT: I also needed to addd projectpath to reference.js, styles.js and serve.js

[seffw]

2nd update:

This works, is cleaner, more adaptable to multiple projects, and doesn't contain config or theme info (this stays in the individual project config file):

var src = path.join(process.cwd(), projectpath);
var dst = path.join(process.cwd(), projectpath + '/public');

gutil.log('src: ' + src + ' dst: ' + dst + ' path: ' + projectpath);

var cmd = 'hugo -s ' + src + ' -d ' + dst;

if (drafts) {
    cmd += ' --buildDrafts=true --verbose=true --baseUrl="http://localhost:3000/" ';
}

This will be much better for me as now to use for different proejcts I just change the variable value in build.js.

Perhaps there is a way to pass this as part of the '$ gulp' command?

[jbrodriguez]

@simplyeffectiveweb sounds nice, glad you got it working.

Yes, you can pass parameters to gulp tasks.

Look into gulp-param or yargs, not sure which one of them is kept more up to date.

[seffw]

Found that process.argv.slice(3) gets the arg and it seems ---env arg allows it to be passed (without gulp assuming that's a task). Can't say I know what --env means, but tt works.

Also, I've made quite a few minor changes, to enable gulp to be run from the main hugo directory and to build whichever site is passed in the gulp params.

I've also added functions to process the theme css, js and images, when the theme is in a main 'themes' directory within the main hugo directory. This is how I use themes.

In other words, the main install of themes stays in the main hugo directory, and each site uses these themes as-is, with customization done through copying / adding of template files into each site's layout directories.

I'm not sure if I should do anything with the changes I've made to your scripts (if it might be useful to others).

[seffw]

Another update.

I removed the following:

var cmd = 'hugo -s ' + src + ' -d ' + dst;

cmd += ' --theme=' + theme;

if (drafts) {
    cmd += ' --buildDrafts=true --verbose=true --baseUrl="http://localhost:3000/"';
}

var result = exec(cmd, {encoding: 'utf-8'});
gutil.log('hugo: \n' + result);

to enable hugo to be run as a separate process.

For me this works better as it means huugo errors show on live reload, and hugo anyway auto updates when the static folder changes.

This emulates what techpeace described on the Hugo dscussion thread (http://discuss.gohugo.io/t/support-for-html-css-js-preprocessors/127/15).