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.
Related
added temporary env variable using the command ($env:REACT_APP_NOT_SECRET_CODE = "abcdef") -and (npm start) based on https://create-react-app.dev/docs/adding-custom-environment-variables/ doc. According to doc, it is supposed to live only for that shell session. But when I restart the app again with just npm start - the variable still exists. How to remove this?
Adding an answer to this in case other folks wind up here and don't see the comments.
The issue here is that restarting the application and restarting the shell are two different things.
To clear out these custom environmental variables, close and restart the shell session, not just the node app.
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.
My console keeps on saying that
"To set up the editor integration, add something like REACT_EDITOR=atom to the .env.local file in your project folder and restart the development server. Learn more"
I cant even find the .env file on my create-react-app.
Thank you in advance.
Create-React-App supports custom environment variables.
The documentation discusses how to declare these variables:
This can be done using two ways: either in your shell or in a .env file. Both of these ways are described in the next few sections.
Through the local environment
The first way is to add it to your local environment:
For instance, if you're using bash, edit ~/.bashrc
Add export REACT_APP_EDITOR=atom to the bottom then restart your terminal (or source ~/.bashrc)
Through .env files in your application
The second way is to create a .env file at the root of your application directory, and add the variable on a single line there:
REACT_APP_EDITOR=atom
From the documentation, these types of files can be declared and will be consumed by Create-React-App:
.env: Default.
.env.local: Local overrides. This file is loaded
for all environments except test.
.env.development, .env.test, .env.production: Environment-specific
settings.
.env.development.local, .env.test.local, .env.production.local: Local
overrides of environment-specific settings.
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.
Is there a plugin to rename a build in Jenkins based on a variable in "Parameterised build"? I tried Build+Name+Setter+Plugin, but it has note in the help section that says
Blockquote
${ENV,var="VARIABLENAME"}
Expands to an environment variable (specified here as VARIABLENAME) from the build environment. Note that this does not include any variables set by the build scripts themselves, only those set by Jenkins and other plugins.
So the format #$jiraissue-${BUILD_NUMBER} (Where jiraissue is parameter passed to the build) didn't work when I tried it. Any suggestions?
I am not a Pro in Jenkins CI but this might be something of your interest.
Build Name Setter Plugin
This worked :)
${BUILD_NUMBER}-${ENV,var="jiraissue"}