I'm setting up a CI using reactjs and I don't want the tests to run in watch mode.
In the documentation for running tests, it states the following:
"By default npm test runs the watcher with interactive CLI. However, you can force it to run tests once and finish the process by setting an environment variable called CI."
If, as stated, setting the 'CI=true':
"The test command will force Jest to run in CI-mode, and tests will only run once instead of launching the watcher."
Why does it (as quoted below) say For non-CI environments? Is there any reason you shouldn't use '--watchAll=false' in CI environments?
"For non-CI environments, you can simply pass the --watchAll=false flag to disable test-watching."
I've tried both in my CI environment and in my case both seems to work fine and doing the same thing. I would even prefer the '--watchAll=false', since this would be a more cross platform approach.
So, which one should I use in my CI environment and why? And also, what's the difference between the two of them?
Thank you!
Wondering which approach I should use 'CI=true' or '--watchAll=false'. I've tried both and they seem to be working in the same way.
Your CI environment will likely set the CI environment variable to true without you doing anything.
So for your CI you shouldn't really need to set either watchAll=false or CI=true but if you do want to set something manually rather use CI=true.
At least one difference between the 2 is that watchAll=false (and if CI=false) will still create Jest snapshots if they don't exist. You won't want this in a CI environment. Your tests will pass even if the snapshots change.
Related
I'm using Turborepo for my monorepo project, i have 2 react apps. How can i configure Turborepo and CircleCI (repos are on Github) so if i make changes to one project that pipeline is not going to run for second project?
I know turbo is using hash algo to check if there is any changes to a project and then rebuild it.
I have tried looking here https://turborepo.org/docs/ci/circleci but does not explain the behavior of this.
Steps would be:
Make code change to Project 1
Commit changes of monorepo to Github
Github detects a commit and triggers CircleCI to run CI/CD
So this part is what I'm not sure, if it triggers CI/CD it will trigger for the both projects right? And if so how can i prevent only for the one i have made changes?
I've been working on such a solution for days now. There are two core-concepts in turborepo to achieve this:
Filtering workspaces
Caching Buildoutputs and store the cache in the cloud (not what you're looking for)
So, you can filter your monorepo for a specific project, e.g:
pnpm turbo run build --filter='my-project...[HEAD^1]' --dry=json
-> This will look if the task build is needed to run for the project "my-project", comparing the current source with "HEAD^1". The option dry=json helps to just look if there would be a need to run "build" or not for "my-project".
You could filter a whole lot more, check the docs.
Now, what i have built on top of this:
A new job on the github workflow looks with the help of this filter command if a deployment of my graphql-server is needed and he will set the output of this decision as an artifact, to provide this information for later jobs (https://github.com/actions/upload-artifact)
My actual docker-build and deploy-to-fly-io jobs that run afterwards, will download this artifact and set a CONTINUE environment variable, depending if it should build + deploy or not.
Every job coming after that is having an if: ${{ env.CONTINUE == 'true' }} to skip them if no build/deploy is needed.
It could be much simpler if you can run your build/deploy job directly with the turbo cli, because then you can just combine your filter and the execution of the build - but that was not possible in my case.
If you need to "skip" jobs that are coming later in your workflow, it's harder thant it should, as github is not supporting "abortion" of jobs.
For all the other commands like lint, typecheck and test -> just add an appropriate filter option to them and you will achieve that they only run on your "affected" workspaces/projects in your PR.
Ressources:
https://dev.to/ngconf/deploying-nx-affected-apps-from-github-actions-54n4
How can I get the previous commit before a push or merge in GitHub Action workflow?
https://github.com/orgs/community/discussions/26313
We're using Jest to perform our React.js unit tests (on the frontend) of our Node.js app which runs in a docker container.
We have set up a Pipeline in Jenkins but I'm unsure of the best way (or best practice) to include the tests as part of the pipeline.
The steps we have are the following:
Check out the code from source control
NPM install and npm run build (front-end)
Docker build + publish
Deploy app
Bump version
Git push
Docker cleanup
I have 3 main queries:
A. I'm assuming it's best to include npm run test between Step 1 and Step 2 and if all tests pass successfully to move further?
B. But how are the snapshots handled? For example, if there's some change which occurred that generates a difference in a snapshot this will not be "checked" back into the source control.
C. I read that people use Cobertura, jest-junit, etc to have unit tests and coverage within Jenkins - what is the best?
Thanks in advance.
Good questions!
A. You can run tests after npm install. And if all tests pass you move further. Another common thing to do is to run linting or code style check.
B. A bad snapshot will fail tests. Which is why it's important to update snapshots before committing. If your jenkins is hooked up to a code review system, you may disable merges that fail builds, to make sure bad snapshots don't get on your master branch.
C. I have seen people use jest-junit, but that's only because there was a requirement to have the coverage report combined with a junit coverage report. If you don't have any particular requirements around the structure of the report, then the default report jest produces should be fine, and you don't need anything extra.
The 0.22.0 version of superset is currently in development.
I am looking for a handy way to change the code in the jsx file and see how it actually works and works.
For example, line 59 of $ SUPERSET_HOME / superset / assets / javascript / addSlice / AddSliceContainer.jsx file looks like this:
{t ('Choose a datasource')}
I want to change this as follows.
{t ('Choose a DATABASE')}
And when I save and refresh it, the changes do not take effect. Restarting superset runserver does not work either.
In order to apply this, I did the following:
Go to the $ SUPERSET_HOME / superset / assets folder
Run the yarn run build again
Go to $ SUPERSET_HOME folder
Run python setup.py install again
Run the superset runserver again
I was able to verify that my jsx changes were applied after I did the above.
But I think this process is too inefficient and time consuming. And I believe there will be a good way to check my changes without repeating the above process.
I am concerned that it may be related to configuration files such as webpack or package.json, but I do not know for sure.
But I have no idea about it.
You can use the command yarn run build --watch to watch and validate the changes you make in the jsx files. This will essentially help in checking for any syntax errors while you're writing the jsx models.
However, to reflect these changes, you will have to build superset again (python setup.py install) and restart the server. :(
I am using create-react-app, Travis CI and netlify. I have a config file that looks like this:
require('dotenv').load();
module.exports = {
API_BASE_URL: process.env.REACT_APP_DATABASE_URL || 'http://localhost:8080'
}
When I try to deploy to Netlify, I get this error in Travis:
Creating an optimized production build...
Failed to compile.
Failed to minify the code from this file:
./node_modules/dotenv/lib/main.js:23
If I remove the require('dotenv').load(); part, it loads, but then the app tries to go to localhost, which is obviously not what I want.
This article: https://github.com/motdotla/dotenv/issues/261
brings up the same issue, but they don't offer a solution. I'm stuck. Help!
disclaimer: I work for netlify.
TL;DR unix shells complicate things.
The preferred way to use environment variables in Netlify is to set them in our environment - be that in the Build Environment Variables configuration widget (second on the "Build & Deploy settings" page - under your the repo+build command section), or via netlify.toml (https://www.netlify.com/docs/continuous-deployment/#deploy-contexts). The latter is a bit more flexible as you can set different values for different contexts - e.g. staging uses a staging DATABASE_URL and production uses a production one.
So - those variables are "available" in the build environment - if your build command were env, then you'd see them - in addition to $PATH and $NODE_VERSION and some other stuff Netlify sets automatically. However, depending on how your build pipeline works, they may or not be available inside of it. If your build command is node -p "process.env" - that will show you what node sees for environment variables - and that should show the same thing as env shows (which is what the shell run by the build script sees).
Unfortunately, many of the build pipelines that folks use DON'T automatically import/inherit variables from the parent shells. This thread shows such an example: https://github.com/theintern/intern/issues/136#issue-26148596 . So - the best practice is not to necessarily use something like dotenv (though that has worked for folks that aren't trying to minify it :) ) - but instead, use a build process that appropriately passes those environment variables that we expose in the shell, into the build environment. How you do that is kind of up to you and your tools.
a further PS: unless your build pipeline DOES something with the environment variable - it's not going to be much use in the code that gets published and served to the browser - which doesn't understand $REACT_APP_DATABASE_URL - that's just a string to the browser. I know you're not trying to do that, but wanted to point it out for folks who might see this answer later - it's a common misunderstanding among newer developers of static sites.
I have a pre-commit hook that runs some tests. This used to work great until the tests started to rely on environment variables. Is there a way to set those environment variables in SmartGit so the pre-commit tests can complete?
Two options:
1) Add your variables to /etc/profile or /etc/launchd.conf and SmartGit will pick them up.
2) Simply launch SmartGit from the shell instead of the desktop environment and your variables from files such as ~/.bashrc will be present. (That's what I'm doing, using a brief alias for convenience.)
SmartGit will pass all environment variables of its own to the forked git process. Hence, if you make sure that SmartGit is started with the correct configuration, your pre-commit hook should work.