In my gradle script I try to use the default system properties. The documentation tells me that teamcity.buildType.id and teamcity.build.id is only set in the system properties an not as environment variables, so my only way is to access them via System.getProperty("%system.teamcity.buildType.id%"). But it tells me it is not defined.
I tried to reference to %system.teamcity.buildType.id% via my own environment variable but it tells me this Parameter "env.teamcity.buildType.id=%system.teamcity.buildType.id%" is not fully resolved, using as is.
I also printed out every system and environment variable. It printed a whole list but not any of the default system properties which should be set by teamcity.
How can I access them and why aren't they not set automatically?
Related
In Quarkus, You can define environment variables that will represent as configuration to your Quarkus app. For example:
DATABASE_PASSWORD=test123
Outside the quarkus app, there is a file that contains a password. The content of this file (being the password) needs to be set to a property in the quarkus app.
Would it be possible to define an environment variable (i.e. a property) that runs a 'cat' command on that file (as the quarkus app is running in a linux environment) and the value is stored in that environment variable?
e.g.
DATABASE_PASSWORD=`cat /var/common/database_secret.txt`
Is this possible? If not would anyone be able to make suggestions for an alternative solution (where we have to have a property whereby the value is from the contents of a file)?
Many thanks.
We are currently set path of properties file which contains secret/access key for Credentials File for AWSCredentialsProviderControlerService . Issue, is we are changing properties path for prod and non prod each time we run nifi workflow. trying to come up no change on Configuration on Credential File path, so that access/secret key would be read regardless of prod and non prod. Since credential file wont support Nifi Expresion language, trying to make use of ACCESS KEY/SECRET properties ${ENV:equalsIgnoreCase("prod"):ifElse(${ACESS_PROD},${ACESS_NONPROD})} Issue we are facing, we are not able to store these access key/secret keys to the registry. Hence unable to implement this change. Is there any way to read access/secret key regardless of environment in Nifi. Curently we are using 1 property file for non prod nifi and 2nd property file for prod properties. In this set up, manually need to changed to credential file path when switching from prod to non prod. Trying to seamlessly work without changing path of credential file. Is there any way to make this happen?
enter image description here
The process that uses the AWSCredentialsProviderControlerService does not support param or variables, but the AWSCredentialsProviderControlerService "credential file" property supports "Parameters Context" as entries, make use of this for your solution.
Example:
Trigger something --> RouteOnAttribute --> If Prod (run executestreamcmd and change the Parameter Context Value to point to prod credfile) else if DEV(run executestreamcmd and change the Parameter Context Value to point to prod credfile) --> then run you AWS Processor.
You can use the toolkit client to edit the parameter context, or event nipyapi python module. It will not be fast tohu.
I've read many questions on this such as:
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/da4bdb11-fe42-49db-bb8d-288dd1bb72a2/sqlcmd-vars-in-create-table-script?forum=ssdt
and
How to run different pre and post SSDT pubish scripts depending on the deploy profile
What I'm trying to achieve is a way of defining a set of scripts based on the environment being deployed to. The idea is that the environment is passed in as a SQLCMD variable as part of the azure-devops pipeline into a variable called $(ServerName), which I've setup in the sql server database project under properties with a default of 'DEV'.
This is then used in the post deployment script like this:
:r .\PostDeploymentScripts\$(ServerName)\index.sql
This should therefore pick up the correct index.sql file based on the $(ServerName) variable. When testing this by publishing and entering 'QA' for the $(ServerName) variable and generating the script it was still displaying the 'DEV' scripts. However, the top of the script showed the variable had been set correctly:
How do I get the post deployment script to reference the $(ServerName) variable correctly so I can dynamically set the correct reference path?
Contrary to this nice post: https://stackoverflow.com/a/54482350/11035005 , it appears that the :r directive is evaluated at compile time and inserted into the DACPAC before the xml profiles are even evaluated so this is not possible as explained.
The values used are the defaults or locals from the build config and can only be controlled from there.
I search a lot on the web, almost all links says define JVM custom variables in jvm.options also placed it on ${server.config.dir}/jvm.options.For example I added a variable called -DAPP_ENV=PROD. But this is getting as NULL after server startup.
Any idea?
It looks like you want to define an environment variable, so you have two options.
1. Use an Environment variable
In this case, you can define an environment variable (like $PATH) and load it in your app. Note this is not a JVM argument, and it will be set in the bin/server shell command used to start the server.
In the file:${server.config.dir}/server.env
Add the following line: APP_ENV=PROD
Access the value with:
System.getenv("APP_ENV"); -> PROD
2. Use a System property
This is what you are trying to do, so I am not sure why it doesn't work for you, but here's how:
In the file:${server.config.dir}/jvm.options
Add the following line: -DAPP_ENV=PROD
Access the value with:
System.getProperty("APP_ENV"); -> PROD
Note that in both cases these values are set at server start-up, and they are not changed dynamically (most Liberty configuration is dynamic). The JVM options and environment are sourced and set during the start script so a restart is required if you want to change either one.
My personal recommendation is go to the server.env route - its more generic and (to me) feels more appropriate since you are trying to influence the execution environment of the process, rather than defining behaviors or configuration of the JVM.
I'm trying to understand about variables in teamcity. My understanding is there are 3 kinds of variables(System,Env,Config)
But in jetbrains documentation I saw more variables. Looks like agent variables and server side variables are separate.
But in TeamCity, parameters section when I select "kind" config or system or env, all kinds of values are populated (I Expected only relevant values should come)
Not really clear about when we have to use which variable. Is TeamCity having 6 variables for parameters(Serverside:env,sys,config and Agent:env,sys,config).
There are three types of parameters, they differ in a way they might be used in a build:
env parameters are passed to the build process (spawned by TeamCity) as environment variable
sys parameters set tool-specific variables (and therefore passed to the build scripts of the supported runners)
config parameters are meant to be used for build configuration customization
There're predefined parameters exposing server build properties, agent properties, agent build properties etc. These parameters are passed to the build as system parameters, some of them are also copied to the environment variables.
In addition, parameters might be defined
for a certain build via "Run Custom Build" dialog
in Parameters section of build configuration/project or build configuration/project template
in buildAgent.properties file on the agent
More details might be found in the docs.