I'm trying to automate building of my project on a TeamCity server. I'm using grunt to define and configure my tasks. This works fine locally. Yet, I am having problems getting TeamCity (running on Windows Server 2008) to recognize grunt as a executable, the build will fail when grunt is called as it is not available.
I do have grunt-cli installed on the server and can execute it when I login via ssh (The build script also succeeds when I trigger it that way).
I'm running npm install before I call grunt and also tried to force install grunt-cli using a preinstall instruction in my package.json like:
{
"name": "someName",
"version": "0.0.1",
"private": true,
"scripts" : {
"preinstall" : "npm install grunt-cli -g"
},
"devDependencies": {
"grunt": "~0.4.1",
"grunt-contrib-jshint": "~0.6.3",
"grunt-contrib-less": "~0.8.1",
"grunt-contrib-watch": "~0.5.3",
"grunt-contrib-requirejs": "~0.4.1",
"grunt-strip": "~0.2.1",
"grunt-bump": "0.0.11"
}
}
I can see npm installing grunt-cli, yet grunt is not available in the next step.
I also tried wrapping that into a bat file or using multiple build steps for dependency installing and running the grunt task.
Does anyone have any input on this?
I had the same problem when trying to get our TFS Build agents to run grunt-cli. In the end I just changed my build process to use the full path to the grunt-cli executable.
So I changed from using this:
grunt deploy
to using this:
"C:\Users\tfsservice\AppData\Roaming\npm\grunt.cmd" deploy
I know this is just a workaround and not a true fix, but it should be good enough to get you going. I hope this helps.
-- Update --
I was able to get it to work properly by simply adding "C:\Users\tfsservice\AppData\Roaming\npm" (where the grunt.cmd file is found) to my system path, and then rebooting my build server. The reboot was required since tfsservice is both a user and a running service; simply restarting the service may be enough, but I didn't test that.
After doing this grunt deploy worked in our builds as expected.
You are running Teamcity agent on Widnows Server?
There is plugin for Node.js/Grunt for Teamcity: https://github.com/jonnyzzz/TeamCity.Node
As far as I've used it had no issue running grunt with Teamcity.
Related
When I run npm run cypress:run in my GitLab CI env I get the error:
Your configFile is invalid: //WebApp/cypress.config.ts
It threw an error when required, check the stack trace below:
TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for //WebApp/cypress.config.ts
test:cypress:
image:
name: cypress/included:10.3.1-typescript
entrypoint: ['']
stage: test
script:
- yarn install --frozen-lockfile
- cd WebApp
- npm run cypress:run
rules:
- *branch
If I run npm run cypress:run from the WebApp folder (where cypress.config.ts is in the root) locally I have no issue. Also no issues when I do an npx cypress:run
However, if I run npx cypress run --config-file WebApp/cypress.config.ts from the parent folder locally I do get the error:
Unknown file extension ".ts"
Any ideas why locally Cypress is working but on the CI the config file is incorrect?
This still seems to be an issues today for LTS 10.10.0
Changing the fresh install cypress.config.ts -> cypress.config.js
and use require like so proved successful.
module.exports = require('cypress').defineConfig({ component: {
devServer: {
framework: "create-react-app",
bundler: "webpack",
},
},
});
I updated this github issue with some more information.
This will be because you have typescript installed globally on your machine so it will work ok locally but not in CI.
Essentially typescript has to be in the folder from where the cypress command is run for it to detect typescript properly.
I went with:
script:
- npm install --global serve
- serve ./build --listen 3000 &
- rm package*
- npm install #percy/cypress typescript
- npm install --global #percy/cli
- percy exec --verbose -- cypress run
Just installing the bare minimum to run the e2e tests ./build is an artifact from another run and percy is really great if you have not used it before.
I am late here, i had similar issue. The del package to delete passed videos was the culprit for me. In the CI environment, it requested to install the del package separately, but in my cypress.config.ts, i was directly able to import del package which was served from third party.
I wanted to install the exact del package in my case and that solved the problem. Del package has its limitations, rimraf solved my issue.
https://www.npmjs.com/package/rimraf
It looks like it's about the version. This might be hepful GitHub
I have tried all different ways suggested in the GitHub issue that
user18025789 linked, but nothing helped. Then I tried switching the config file from .ts to cypress.config.js and it started to work (syntax needed to be updated to JavaScript as well). I have no idea why.
I came across this issue because Typescript was not installed in my Cypress container. When ts-node doesn't have access to typescript, it's require behaves like the native "require", which is why you're seeing the error.
I don't know enough about your specific setup to recommend a solution, but for me I was able to run npm i and mount the volume in the cypress container before running the tests. Another option could be to create a new Dockerfile to extend the base Cypress image with typescript included in the build.
If working on a monorepo and mounting only the app/package folder to test into the cypress docker image, not all dependencies are available within this directory.
To fix this mounting, the whole workspace does the job:
cypress:
image: cypress/included:10.11.0
# …
working_dir: /workspace/app
volumes:
- ..:/workspace
I started facing this issue, suddenly, My solution wasrm -rf node_modules package-lock.jsonnpm i I already had the cypress.config.ts file, so cypress test runner picked it up, when I rannpx cypress open
I have an app initiated using Create React App, so npm run build runs react-scripts build. I recently installed prettier and so added a .eslintrc.json file to the project root to load the prettier plugin. npm run build works as expected locally, but, when deploying the app to Heroku, npm run build tries to run ESLint and fails because the plugins are devDependencies rather than dependencies.
Failed to load plugin 'prettier' declared in '.eslintrc.json': Cannot find module 'eslint-plugin-prettier'
From prior wrangling with a similar issue, I know that I can set NPM_CONFIG_PRODUCTION=false in Heroku so that it will install devDependencies, which actually does resolve the deployment issue. Nevertheless, I'm curious to learn if there's another solution that doesn't require setting NPM_CONFIG_PRODUCTION=false.
Is it possible to prevent npm run build in this scenario from running ESLint altogether or to prevent it from trying to access the plugins specified in .eslintrc.json? I acknowledge that adding .eslintrc.json to .gitignore is one solution, but I want the ESLint configuration in my repo.
you can run "npm run eject" to generate webpack configuration files, and then modify "webpack.config.js"，delete the eslint configuration
Could you please give me some advise on how to deal with this issue.
Build Pipeline
npm install
package.json
"dependencies": {
"cypress": "^3.4.1"
}
Release
Powershell command
npm ./node_modules/.bin/Cypress run
The cypress npm package is installed, but the Cypress binary is missing.
2019-10-07T18:04:59.5720120Z We expected the binary to be installed here:
There are some examples on how to cache ~/.npm but nothing seems to work so far. Examples on how to include cypress.io in your vsts are at the building stage and not after release.
According to the error log, it has provided a solution about this. You should run the cypress install command first and then the error will be fixed.
As my test, since I don't have a cypress.json file, so I need run the open command to
automatic generated get the json file and project sample.
Then the open command run as expected.
But because I run the open command in interactive mode and I don't have the cypress.json file in my artifacts, the taks finally failed.
So if you have cypress.json in your repo or artifacts, you just need to add
.\cypress install
in your powershell command.
And if not, you can add the related json file and folder to your repo or artifacts and then the run command will work as your expected.
I used aurelia-cli to setup my Aurelia application on top of the backend in asp.net WebAPI.
I run backend from visual studio on a port in localhost, which exposes the api endpoints. Then I open git bash from my project directory to do au run which runs my Aurelia frontend on localhost:9000
On Visual Studio online, it builds my backend project even if I made a change to one of the typescript files within Aurelia. But the artifact created by build process doesn’t have any .ts files. This is similar to if I were to publish from visual studio.
To publish Aurelia, I do au build -–env prod separately on git bash from project directory, that bundles files into app-bundle.js and vendor-bundle.js inside wwwroot/scripts directory.
So I have two different projects for Aurelia and webAPI. The question is can I build both together in visual studio online/TFS?
I tried adding a shell script with the au build –-env prod command as a task to my build process. It tried to run from the temp location where it drops the artifacts eg: d:\a\1\s\mycommand.sh . Aurelia isn’t installed there, so I got au command not found error.
If not together, can I run the aurelia project separately from vs online so I get the bundled js files that I can then use to deploy, without having to run the commands from git bash?
Update: after writing this post, I got this post in suggestion How to optimize workflow with single project using Aurelia CLI / ASP.NET Core
which mentions "the au build command is executed in the precompilation target, so when I build or run the ASP.NET Core project from Visual Studio using F5, Aurelia CLI will build and bundle the assets for the Aurelia app into wwwroot as well."
It doesn't say how to do it, that is what I'm trying to achieve. Perhaps asking question as an answer is not advised so I asked it here.
There are many ways that can call au command:
Install Aurelia cli in a folder:
Include aurelia-cli package dependence in package.json file (dependencies or devDependencies) or install it directly through Command line task (Put package.json file in the target folder that you want to call au command)
Add au build command to scripts of package.json
Sample:
{
"name": "autest",
"version": "1.0.0",
"description": "",
"main": "index.js",
"dependencies": {
"aurelia-cli": "^0.32.0"
},
"devDependencies": {},
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"aubuild": "au build --env stage"
},
"author": "",
"license": "ISC"
}
Install package through NPM build task (Command: install; Working folder with package.json: package.json folder path)
(Option 1) Call NPM command through NPM build task (Command: custom; Working folder with package.json: package.json folder path; Command and arguments: run aubuild)
(Option 2) Call au command through Command Line task (Working folder: Aurelia-cli package installed path; Tool: node_module\.bin\au; Arguments: build --env stage)
Install Aurelia cli in global:
Add command line task (Tool: npm; Arguments: install aurelia-cli -g)
Call au command in any folder
Regarding "the au build command is executed in the precompilation target”, you can try to build the project through Visual Studio task and check the result.
I have developed a node.js npm module, developing under Windows. Today I wrote some Mocha tests. After many struggles, it seemed that for npm test to work, package.json had to look like this: (there may be other options???)
"scripts": { "test": "node node_modules/mocha/bin/mocha" }
instead of what's in all the Unix based books,
"scripts": { "test": "./node_modules/.bin/mocha" }
How can I set package.json up to work on both Windows and Unix? I'm assuming that Travis-CI runs Unix, so, should I link the build to that, it will blow up with the Windows version.
I found a two year old thread where somebody requested a feature for exactly this. That thread seemed to die out. This SO question seems to be close, but it isn't exactly what I want and, frankly, I can't understand the answer. :-( Can anybody clarify?
For the time being, I am going
"scripts": {
"test": "node node_modules/mocha/bin/mocha",
"testOnUnixUseThis" : "./node_modules/.bin/mocha (I think)",
"testOnWindowsUseThis" : "node node_modules/mocha/bin/mocha"
},
Unfortunately, you cant go npm test testOnWindowsUseThis or npm testOnWindowsUseThis. And it doesn't fix the Travis-CI issue. But at least a person who downloads the module can (hopefully) see what is going on.
Any better ideas? Am I the only person still developing under Windows??? :-)
I've always been able to npm install -g mocha or npm install mocha and then just add
"scripts": {
"test": "mocha spec"
}
to package.json. That may or may not work in EVERY environment. I know, for instance, with lineman, you have to use bin/mocha. Also, if you don't find a way around this, set your test script up for Unix and then add a second script called "wintest" or something that does whatever you need it to do in Windows. You can name your scripts whatever you want. The default ones (test, start, etc.) can be used with npm [command]; any non-standard ones (like wintest) can be used with npm run-script [command], and they will still work.
A little back story on how/why this works:
When you install a module globally, it's available on PATH (or whatever the windows equivalent is). When you install a project dependency, if that module has any binaries, those are symlinked to node_modules/.bin and when you run npm run [some-command], npm helpfully adds node_modules/.bin to PATH for that command. So when mocha is installed globally "test": "mocha spec" uses your globally installed mocha to run tests. When it's a project dependency, it uses the one in node_modules/.bin. The one gotcha I've found with this is that npm adds node_modules/.bin to the front of PATH, so local binaries will always take precedence over global ones. Almost all of the time, this is what you want, but it's worth knowing that that's how it works (I recently had a bug related to this).
EDIT:
Not sure at what point in npm history this changed, but npm run <script-name> now works (don't need to do npm run-script <script-name> anymore). Possibly run-script still works as well. I'd expect it to, but I haven't tried it.
How can I set package.json up to work on both Windows and Unix?
If you
use Windows
dislike -g global install
...this is a working solution
"scripts": {
"test": "node node_modules/mocha/bin/mocha.js"
},
Notes:
putting node in front shouldn't harm, and can help on Windows (.js extension is not necessarily registered to the nodejus executable, unless you set it so. Could open a text editor, an IDE or (worse) windows scripting host, Internet Explorer…)
Adressing the script directly saves you from needing a global install. (Not judging if this is a good practice)
forward slashes help running under linux (obviously) and do work under windows (in this scenario. Also avoids a windows pitfall: backslashes if used, would need to be doubled – since they are interpreted as escaping the following letter if used solitary).
Don't use global solution, I suggest you follow what the Mocha guys say:
"scripts": {
"test": "node_modules/.bin/mocha -w"
},
Use npm i mocha --save-dev
This will save the module as a development dependency and npm will automatically set up the executables to be used within the scripts object. If you want to use the executables outside of the scripts defined in package.json, you can install it globally as well, although note that you may end up with different versions of the package.
If you only install it globally, other people won't be happy if they try to run your tests (with the standard npm test)
The new way with latest npm versions after 6.x, you needn't install mocha with global mode any more.
"scripts": { "test": "npx mocha" }
npx is installed automatically with new npm installation. It will search
mocha from node_modules/.bin or $PATH
reference: https://www.npmjs.com/package/npx