Right now, I'm trying to build a tool from source and use it to build a C++ project. I'm able to extract the tar file (gcc-arm-none-eabi). But, when I try to add it to path (using $GITHUB_PATH, not add-path), the path doesn't apply on my next action and I can't build the file. The error states that it can't find the gcc-arm-none-eabi toolset, which means that it didn't go to path.
Here's the script for the entrypoint of the first function (make is ran in the next action to allow for path to apply)
echo "Downloading ARM Toolchain"
# The one from apt isn't updated so I have to build from source
curl -L https://developer.arm.com/-/media/Files/downloads/gnu-rm/10-2020q4/gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2 -o gcc-arm-none-eabi.tar.bz2
tar -xjf gcc-arm-none-eabi.tar.bz2
echo "/github/workspace/gcc-arm-none-eabi-10-2020-q4-major/bin" >> $GITHUB_PATH
I can't even debug by seeing what's in the path because running echo $(PATH) just says that PATH cannot be found. What should I do?
I can't even debug by seeing what's in the path because running echo $(PATH) just says that PATH cannot be found. What should I do?
First, PATH is not a command so if you want to print its value, it would be something like echo "${PATH}" or echo "$PATH"
Then, if you want to add a value to an existing environment variable, it would be something like
export PATH="${PATH}:/github/workspace/gcc-arm-none-eabi-10-2020-q4-major/bin"
EDIT: seems not a valid way to add something to the path using Github Actions, meanwhile it seems correct in the question. To get more details: https://docs.github.com/en/free-pro-team#latest/actions/reference/workflow-commands-for-github-actions#adding-a-system-path . Thanks to Benjamin W. for pointing this out in the comments.
Finally I think it would be a better fit if you use a docker image that already contains that kind of dependancies (you could easily write your own Dockerfile if this image doesn't already exists). Github action is designed to use docker (or OCI containers) image that contains the dependancies you need to perform your build actions. You should take a look here: https://docs.github.com/en/free-pro-team#latest/actions/creating-actions/dockerfile-support-for-github-actions
I need to run npm install && gulp build inside my static/semantic-ui folder, so it creates the needed css file.
I saw this example with Setup.hs, however on my scaffolded project I don't have it, so my question where is the right place to put the code to run those bash commands.
If you're using the default Yesod scaffolding (generated by stack tool), then it indeed doesn't contain Setup.hs (which is a bit weird, as their own guide - https://github.com/commercialhaskell/stack/blob/master/doc/GUIDE.md - recommends having it as a good practice)
Setup.hs should be located in main project directory (same where stack.yml and yourproject.cabal are located) and content should be roughly the same as in your included example (defaultMainWithHooks is the key part).
Details of hooks usage are specified in https://www.haskell.org/cabal/users-guide/developing-packages.html and in cabal spec: https://hackage.haskell.org/package/Cabal-1.24.0.0/docs/Distribution-Simple.html
BTW, for now stack doesn't support pre-build hooks on its own (for details see: https://github.com/commercialhaskell/stack/issues/503), so you have to stick to ones provided by cabal - that's where Setup.hs comes from.
I'm trying to build my Electron app with Electron-packager. The problem is my Electron app using node-notifier module. When the packaging, I'm using this command:
electron-packager . MahApp --ignore='node_modules|.sass-cache|src' --platform=darwin --arch=x64
but the problem is that command ignores all node modules. So I edited like this:
electron-packager . MahApp --ignore='node_modules\/(?!node-notifier).+|.sass-cache|src' --platform=darwin --arch=x64
It seems working because only 'node_modules/node-notifier' is inside of resources/app. But it won't work because node-notifier module itself has extra node modules under the node_modules directory like this:
./MahApp/node_modules/node-notifier/node_modules/...
So it didn't work because any dependencies are not exists. My regex in --ignore_path also ignored inside of node_modules in node_notifier. I don't know what should I do now. I tried to specify the relative path like this:
--ignore='./node_modules\/(?!node-notifier).+|...'
but it wasn't work.
Do you actually need the node-notifier module? If not, you can npm uninstall node-notifier --save, or alternatively, put it only in dev-dependencies and run it with --prune option
Mocha tries to find test files under test by default, how do I specify another dir, e.g. server-test?
Use this:
mocha server-test
Or if you have subdirectories use this:
mocha "server-test/**/*.js"
Note the use of double quotes. If you omit them you may not be able to run tests in subdirectories.
Edit : This option is deprecated : https://mochajs.org/#mochaopts
If you want to do it by still just running mocha on the command line, but wanted to run the tests in a folder ./server-tests instead of ./test, create a file at ./test/mocha.opts with just this in the file:
server-tests
If you wanted to run everything in that folder and subdirectories, put this into test/mocha.opts
server-tests
--recursive
mocha.opts are the arguments passed in via the command line, so making the first line just the directory you want to change the tests too will redirect from ./test/
Here's one way, if you have subfolders in your test folder e.g.
/test
/test/server-test
/test/other-test
Then in linux you can use the find command to list all *.js files recursively and pass it to mocha:
mocha $(find test -name '*.js')
The nice way to do this is to add a "test" npm script in package.json that calls mocha with the right arguments. This way your package.json also describes your test structure. It also avoids all these cross-platform issues in the other answers (double vs single quotes, "find", etc.)
To have mocha run all js files in the "test" directory:
"scripts": {
"start": "node ./bin/www", -- not required for tests, just here for context
"test": "mocha test/**/*.js"
},
Then to run only the smoke tests call:
npm test
You can standardize the running of all tests in all projects this way, so when a new developer starts on your project or another, they know "npm test" will run the tests. There is good historical precedence for this (Maven, for example, most old school "make" projects too). It sure helps CI when all projects have the same test command.
Similarly, you might have a subset of faster "smoke" tests that you might want mocha to run:
"scripts": {
"test": "mocha test/**/*.js"
"smoketest": "mocha smoketest/**/*.js"
},
Then to run only the smoke tests call:
npm smoketest
Another common pattern is to place your tests in the same directory as the source that they test, but call the test files *.spec.js. For example: src/foo/foo.js is tested by src/foo/foo.spec.js.
To run all the tests named *.spec.js by convention:
"scripts": {
"test": "mocha **/*.spec.js"
},
Then to run all the tests call:
npm test
See the pattern here? Good. :) Consistency defeats mura.
If in node.js, some new configurations as of Mocha v6:
Option 1: Create .mocharc.json in project's root directory:
{
"spec": "path/to/test/files"
}
Option 2: add mocha property in project's package.json:
{
...
"mocha": {
"spec": "path/to/test/files"
}
}
More options are here.
Don't use the -g or --grep option, that pattern operates on the name of the test inside of it(), not the filesystem. The current documentation is misleading and/or outright wrong concerning this. To limit the entire command to a portion of the filesystem, you can pass a pattern as the last argument (its not a flag).
For example, this command will set your reporter to spec but will only test js files immediately inside of the server-test directory:
mocha --reporter spec server-test/*.js
This command will do the same as above, plus it will only run the test cases where the it() string/definition of a test begins with "Fnord:":
mocha --reporter spec --grep "Fnord:" server-test/*.js
Now a days(year 2020) you can handle this using mocha configuration file:
Step 1: Create .mocharc.js file at the root location of your application
Step 2: Add below code in mocha config file:
'use strict';
module.exports = {
spec: 'src/app/**/*.test.js'
};
For More option in config file refer this link: https://github.com/mochajs/mocha/blob/master/example/config/.mocharc.js
Run all files in test_directory including sub directories that match test.js
find ./parent_test_directory -name '*test.js' | xargs mocha -R spec
or use the --recursive switch
mocha --recursive test_directory/
I had this problem just now and solved it by removing the --recursive option (which I had set) and using the same structure suggested above:
mochify "test/unit/**/*.js"
This ran all tests in all directories under /test/unit/ for me while ignoring the other directories within /test/
As mentioned by #superjos in comments use
mocha --recursive "some_dir"
I am on Windows 7 using node.js v0.10.0 and mocha v1.8.2 and npm v1.2.14.
I was just trying to get mocha to use the path test/unit to find my tests,
After spending to long and trying several things I landed,
Using the "test/unit/*.js" option does not work on windows.
For good reasons that windows shell doesn't expand wildcards like unixen.
However using "test/unit" does work, without the file pattern.
eg. "mocha test/unit" runs all files found in test/unit folder.
This only still runs one folder files as tests but you can pass multiple directory names as parameters.
Also to run a single test file you can specify the full path and filename.
eg. "mocha test/unit/mytest1.js"
I actually setup in package.json for npm
"scripts": {
"test": "mocha test/unit"
},
So that 'npm test' runs my unit tests.
If you are using nodejs, in your package.json under scripts
For global (-g) installations: "test": "mocha server-test" or "test": "mocha server-test/**/*.js" for subdocuments
For project installations: "test": "node_modules/mocha/bin/mocha server-test" or "test": "node_modules/mocha/bin/mocha server-test/**/*.js" for subdocuments
Then just run your tests normally as npm test
This doesn't seem to be any "easy" support for changing test directory.
However, maybe you should take a look at this issue, relative to your question.
As #jeff-dickey suggested, in the root of your project, make a folder called test. In that folder, make a file called mocha.opts. Now where I try to improve on Jeff's answer, what worked for me was instead of specifying the name of just one test folder, I specified a pattern to find all tests to run in my project by adding this line:
*/tests/*.js --recursive in mocha.opts
If you instead want to specify the exact folders to look for tests in, I did something like this:
shared/tests/*.js --recursive
server/tests/graph/*.js --recursive
I hope this helps anyone who needed more than what the other answers provide
Another option in windows could be using cross-env package and following npm script in package.json
"scripts": {
"test": "cross-env mocha '*.test.js'"
},
"devDependencies": {
"cross-env": "latest",
}
In this case all test files with pattern *.test.js in root folder will be run by mocha.
I have packages SASS and SCSS installed. SCSS provides the syntax highlight while SASS provides the build system i need for scss. My problem is, if build is set to automatic, it wont build the scss files if i press ctrl+b, so i have to always go back and reselect that option. Is there a way to make that build system to be the automatic one for scss?
Set it up using a build system and fire off with F7:
http://readthedocs.org/docs/sublime-text-unofficial-documentation/en/latest/file_processing/build_systems.html?highlight=build for more information about setting that up.
UPDATED ANSWER
Copy the following:
{
"cmd": ["sass", "--update", "$file:${file_path}/${file_base_name}.css", "--stop-on-error", "--no-cache"],
"selector": "source.sass, source.scss",
"line_regex": "Line ([0-9]+):",
"osx":
{
"path": "/usr/local/bin:$PATH"
},
"windows":
{
"shell": "true"
}
}
In Sublime Text, go Tools > Build System > New Build System > Paste
Give it a name. Bingo.
Simpler Way
SASS Support in Sublime
Adding Support for near everything.
Simplest Way
Why DIY when you do not need to.
Want to have the site update in an open browser every time you save?
Generally a good must to have Ruby Git and Python installed.
Install Nodejs.
(win) the .msi download from main site works well and includes npm
Now you have access to the 'gem' and 'npm' package managers.
Things get easy now, although I may as well write it out longwinded.
Compass:
gem update --system
gem install compass
// can now use this command to build a sass-based project
compass create myFirstWebsite
// ..installs in "/myFirstWebsite"..
Install the Grunt client (global flag)
npm install grunt-cli -g
now have access to the wealth of Grunt automation packages ie:
npm grunt-contrib-jshint --save-dev
"dev" flagged - applies to your local project only (current and sub folders)
also, listed as a "devDependency" in package.json, which means it'll not be
packed with your project on a distro/prod build
Time for some simple awesome... Yeoman
npm install yo -g
installs yeoman (yo commands) a heap of other essentials
and Bower - twitter's response to Node / Gem etc
Bower looks after package dependencies.
AND THE AWESOME?
// make a new folder. cd into it, and type:
yo webapp
// There are multiple 'generators' you can install with yo.
// webapp is the one most suitable for front-end dev / web app building
// other things you might want before you start.. maybe underscore:
bower install underscore
// adds '_' to the set-up as a dependency
// These commands will brighten your day:
grunt test
// comprehensive testing of app
grunt server
// This part you'll love! Starts server and launches app in browser
// - includes live-refreshing... save a file, and all required builds etc
// are preformed (damn fast) and automatically refreshes browser.
// Yup, 'grunt server' = project-wide equiv to 'compass watch'
grunt
// Build application for deploy. Not only do you get minification and concatenation;
// also optimize all your image files, HTML, compile your CoffeeScript and Compass files,
// if you're using AMD, will pass those modules through r.js so you don't have to.