App.module defines environment variables to be used globally.
For other controllers, environment variables are well applied when building.
Only a specific controller (user.controller) is not defined.
Instead, call user.controller via api after build, and you will see the environment variable log.
Please tell me why.
https://github.com/yj2dev/Lightning-marketplace-Clone
https://github.com/yj2dev/Lightning-marketplace-Clone
just don't use process.env directly whenever possible. Use some provider like ConfigService from #nestjs/config. Read the docs site. Otherwise you'll need to use dotenv like any other nodejs project
Related
I'm new to AWS and DevOps. But still experimenting here on our project, and I saw this environment variables section in CodeBuild, and I was trying to console.log the ENVIRONMENT which is sgdev1, but I'm getting undefined, when I check on CloudWatch.
I console log it like this, since I saw in our codebase it's written like that to access the environment variables. Though in this way, I'm only sure that it fetches those variables stored in my local machine, in the environment variables in Windows OS.
console.log(process.env.ENVIRONMENT)
Also I'm not that really sure where to put the environment variables, I'm quite confused since we also uses was secrets manager which holds some of our variables, then there's this codebuild env variables. I'm confused where should the variable that identify if the server is a dev site or production, but anyways the original question is how can I read these variables from codebuild environment variables? Forgive me if something stupid is going on with my question.
I'm going to assume you're trying to use those environment variables in your dev environment outside of CodeBuild. Those environment variables are only valid for the life of the container which your CodeBuild project is running on and are there for your build scripts to use. Where ever your code is deployed, won't have those environment variables.
I've got a cloud function that needs to install dependencies from a private pypi.
I've set up a secret called pypi_password for the project and given it the correct value.
I've set up a service account to do deployment and given that service account roles/secretmanager.secretAccessor.
I've added --update-secrets PYPI_PASSWORD=pypi_password:latest to my deploy command so the function should have access to the secret.
I've added --extra-index-url=https://account:${PYPI_PASSWORD}#pypi.my-company.com/pypi to my function's requirements.txt.
When I deploy, I briefly see
before the during-deployment pip install fails because my credentials aren't right.
To investigate, I've gone and added an extra ${PYPI_PASSWORD} in my requirements.txt to a portion that's not starred-out in deploy's printed outputs, like: --extra-index-url=https://${PYPI_PASSWORD}account:${PYPI_PASSWORD}#pypi.my-company.com/pypi.
What I see is that the value of ${PYPI_PASSWORD} is coming out as %7BPYPI_PASSWORD%!D(MISSING), which makes it seem like the environment variable doesn't exist.
But shouldn't the secret be accessible as an environment variable this way? This makes no sense to me, and I can't find a solution in the documentation.
I've discovered that I need to make a distinction between run time variables and build time variables.
Basically, by trying to access a Secret in a requirements.txt, I'm trying to use it before it's fully defined and available. The only variables accessible when the dependencies are being installed are build variables.
If I put my password in one of those, it works, so this means Secrets are only available at run time, which makes them kind of useless for this. (ahem, Google)
I'm not so happy about still having the password in plain text for anyone who can view the function, but at least this gets it out of the source code.
When I am calling an api with normal api calling in postman and running a test script and setting environment value, it's working but when I use that api in postman flow, environment doesn't changing.
Script in my test:
pm.environment.set('email', body.email)
Looks like you are looking for this issue from discussions section of Postman Flows repository:
https://github.com/postmanlabs/postman-flows/discussions/142. Here are some key points from it:
I want to begin by saying that nothing is wrong with environments or variables. They just work differently in Flows from how they used to work in the Collection Runner or the Request Tab.
Variables are not first-class citizens in Flows.
It was a difficult decision to break the existing pattern, but we firmly believe this is a necessary change as it would simplify problems for both us and users.
Environment works in a read-only mode, updates to the environment from scripts are not respected.
Also in this post they suggest:
We encourage using the connection to pipe data from one block to another, rather than using Globals/Environments, etc.
According to this post:
We do not supporting updating globals and environment using flows.
I have the following user provided env variable defined for my app hosted in cloudfoundry/pivotal webservices:
MY_VAR=test
I am trying to access like so:
System.getProperty("MY_VAR")
but I am getting null in return. Any ideas as to what I am doing wrong would be appreciated.
Environment variables and system properties are two different things. If you set an environment variable with cf set-env my-app MY_VAR test then you would retrieve it in Java with System.getenv("MY_VAR"), not with System.getProperty.
A better option is to take advantage of the Spring environment abstraction with features like the #Value annotation. As shown in the Spring Boot documentation, this allows you to specify values that get injected into your application as environment variables, system properties, static configuration, or external configuration without the application code explicitly retrieving the value.
Another possibility leaning on Scott Frederick's answer (sorry, I can't comment on the original post):
User provided env vars can easily be accessed in the application.yml:
my:
var: ${MY_VAR}
You can then use the #Value-Annotation like this:
#Value("${my.var}")
String myVar;
I want to be able to use the job and build number within my cloudbees application (i.e access it as an environment variable).
In the application description, I can use "${JOB_NAME} #${BUILD_NUMBER}", but is this also possible somehow within the environment override fields?
I want to be able to set something like:
Name: runningversion
Value: ${JOB_NAME} #${BUILD_NUMBER}
I am assuming you are using the CloudBees Deployer plugin to deploy your application to our RUN#cloud service.
If that is the case then you can achieve exactly what you want with the Override Environment section. You just need to do something like this:
The in-line help for the Value field even indicates that it
Supports ${} style token macro expansion
As a hint to let you know that you can do what you are trying to do... so if it doesn't work then there is a bug!
Those Override Environment name-value pairs should be available, at least, as OS level environment variables and for the Java based ClickStacks (e.g. Tomcat, JBoss, Glassfish, Play, etc) they should also be available as Java System Properties but that can require that the ClickStack is written to provide that support (the well known ones produced by CloudBees should)