Gulp@1 doesn't respect projects in subfolders

[andrewconnell]

Required Information

Type: Bug
Enter Task Name: Gulp@1 & Gulp@0

Environment

• Azure Pipelines?
  • account: aconn
  • project: Voitanos.azure-pipelines-spfx-templates
• Agent - Hosted & Private: (both)
  • Hosted: Hosted Ubuntu 1604 / ubuntu-latest
  • Private: Ubuntu 16.04

Issue Description

I'm creating reusable templates for a specific project type (SharePoint Framework). Most consumers of the templates (such as this test project) will have their projects in the root repo. However, I've added another project to my repo that contains the templates. To support both scenarios, I support the consumer of the template to specify the working_directory as a path to the subfolder of the project if it is not in the root of the repo.

Task Gulp@1 does not respect the workingDirectory or gulpFile input parameters to set the path to a subfolder in the repo; it always looks for the gulpfile.js in the root of the current repo.

Task Gulp@0 does respect the gulpFile input parameter to set the path to a subfolder in the repo (IOW, this works & is what I'm doing now), but workingDirectory is not respected.

See this thread in the DevOps forum where someone from MSFT confirms the issue: https://developercommunity.visualstudio.com/content/problem/716337/unable-to-set-workingdirectory-on-gulp.html

If you look at the highlighted code in this specific commit, you'll see two tasks: script & Gulp@0. This commit is working, but it shows how the workingDirectory folder on the script task is working as expected, CD'ing into the subfolder before executing the command. However, I can't do the same thing with Gulp@*, rather I have to explicitly set the path to the gulpfile.js

From my POV, on the Gulp@1 task, the workingDirectory input property should cause the task to CD into the folder specified before running gulp or gulpjs, similar to how the ShellScript task works. As it's working now, workingDirectory is ignored in both v0 & v1 of the task & setting the gulpFile input property on v1 does not work. Further, the use of workingDirectory is not consistent in the Gulp@* tasks compared to other tasks.

[moswald]

@andrewconnell I'm not seeing what you're seeing, but I don't want to toss this back as "can't repro". Can you provide logs for a failing build? Run with system diagnostics enabled. Thanks!

[andrewconnell]

I can still repro it... did you notice the link to the public forum post where someone from MSFT was also able to repro it?

Here's a project that shows it in action: https://github.com/Voitanos/azure-pipelines-spfx-templates. It is a public repo that contains job templates for a specific type of dev. The sample in the project demonstrates the issue.

Working sample using "Gulp@0" + workaround

The project within ./sample contains the pipeline... the master branch uses the task Gulp@0 without the workingDirectory property and building the path to the gulpfile.js using the gulpFile property as suggested for a workaround in the public forum referenced in my OP.

You can see a working build from the master branch: https://dev.azure.com/aconn/Azure%20Pipelines%20SPFx%20Templates/_build/results?buildId=501&view=logs&s=6884a131-87da-5381-61f3-d7acc3b91d76

Repro sample using "Gulp@1" that doesn't work using the workingDirectory property

The same exact project, except it uses Gulp@1 & the workingDirectory property. This fails as it doesn't incorporate the working directory. You'll find this in the branch repro-gulp-task-build. This commit shows what I changed from the working sample above.

You can see a breaking build from the repro-gulp-task-build branch (this has the diagnostic logging turned on... the immediate preceeding pipeline run is without diag logging turned on): https://dev.azure.com/aconn/Azure%20Pipelines%20SPFx%20Templates/_build/results?buildId=568&view=logs&s=6884a131-87da-5381-61f3-d7acc3b91d76&j=412f6483-90be-5dc3-b7d8-26e9cdfda42a

[moswald]

If you look at the task source, you'll see that we check for the existence of the gulpfile before we set the current working directory based on the input parameter. The difference between your two pipelines is that you're setting a full path to the gulpfile for your Gulp@0 pipeline, but only relying on the working directory in the Gulp@1 pipeline. If you present the same options to the Gulp@0 task, it will fail in the same way.

Technically this is a breaking change, but Gulp@1 is still in preview and it's probably ok for me to fix this so that it sets the working folder first. I will talk to the primary maintainer on the Tasks repo and get back to you. --Also, while I'm here, it's annoying that the gulpFile input is "required" but we also provide a default value. Those are conflicting specifications in my view, and I'll fix that at the same time.

[andrewconnell]

Makes sense... thanks for looking into it.

FWIW, when setting the workingDirectory parameter, I would expect the task would essentially change the PWD => that folder before continuing to look for the gulpfile.js, similar to what the Script tag does (ex: how I'm using it)

Agreed on the requested part about the gulpFile parameter. A default value (where I suspect 99.999% of all projects use the name gulpfile.js) should make it optional.

[moswald]

No problem! Agreed, I'm going to change Gulp@1 to set the PWD before searching for the gulpfile. The fix will go out with our next round of deployments, which is about three weeks out.

[andrewconnell]

[moswald]

Fixed with #11361.