Is it possible to use environment variables in Orbeon service URLs? - orbeon

For example, in our Orbeon test environment we'd like the service URL to be: https://test.some-endpoint.com/validate.
Then when the form is deployed in the production environment, the service URL should automatically change to: https://prod.some-endpoint.com/validate.
I recognize that I could create a hidden field to store the environment value, but this wouldn't automatically change when the form is deployed in the production environment. See screenshot:

Starting with Orbeon Forms 2020.1, you can use the environment-variable('SERVICE_HOST') function. So, assuming you have a environment variable named SERVICE_HOST, in the HTTP Service Editor you can use the following for the Resource URL:
https://{environment-variable('SERVICE_HOST')}.some-endpoint/validate

Related

Is there a way where we can set system environment variables separately for each App while deploying the stream

We are using a third part security library which requires a system environment variable to be set. Can we pass as parameter in stream definition or while deploying stream separately for each app?
I didn't try this myself, but it looks like you can set the desired environment variable for the Spring Cloud Data Flow Server and then also add it to spring.cloud.deployer.local.envVarsToInherit.

Jenkins custom email notifications

We run several environments within Amazon AWS and have a Jenkins server in each environment. Because we use the EC2 hostnames it's difficult to determine which environment the Jenkins is part of.
Therefore each Jenkins has a file called /etc/environment.txt which contains a environment name (e.g. "DEV4").
Question: How, in the email notifications, can I grab the contents of the file above and set it in the subject line of the email?
Would it be possible to overwrite the template? (I'm yet to find where the template file is..)
Thanks
You have many options:
Use the EnvInject Plugin to load a properties file. You need to change the file to become a valid properties file (the contents needs to change to something like env=DEV4).
define a global parameter (manage Jenkins -> configure System)
define an environment variable on OS level
All three solutions will provide an additional environment variable that can be used within the plugin.
Alternatively, just change the default template of the email notification (needs email ext plugin) to contain the env name.

How do I access a configuration variable passed into grails from the commandline

I am trying to send a variable to my grails app through the command line similar to this:
grails -Dmy.build.number=33 prod war ROOT.war
I have tried to access it as grailsApplication.config.my.build.number but I get an empty map. It seems odd that the variable is defined but not set to what I send.
How do I access the command-line property?
I am planning on putting some of my assets(css,js,images,etc) in cloudfront to act as a cdn. So in my build phase I want to use the build number as a cache buster and set my assets to point to mycloudfronturl/assets/${buildnumber}/script.js. If there is a better approach, I'm open to that as well.
System.getProperty("my.build.number");

unable to set environment property in fitnesse setup page

I have been trying to set a environment variable property for DB connection parameters via a fitnesse suite setup page.
I have tested this by setting the environment variable on an individual test page, and when I do this it does get resolved in my fixture API. But when I remove it from the test page and include it in the fitnesse setup page, it can't be resolved in my fixture API for some reason.
This is the COMMAND_PATTERN string I have included to add the environment property:
!define COMMAND_PATTERN {java -cp %p -Ddbadapter.config=classpath:/properties/fiAdapter-config.properties %m}
So this very string is correctly resolved when defined on a test page, but I move it out to the setup test page (which I know is successfully passing down other page level params to the tests), its not resolvable in my fixture API.
I have also tried specifying this property on startup of the fitnesse server:
java -jar -Dadapter.config=classpath:/properties/fiAdapter-config.properties fitnesse.jar -p 6538
and this doesn't isnt working for me either. The only way I can get this working is by specifying the parameter on each test page and that is defeating the purpose of using a properties file for this.
Any idea on what is causing this would be appreciated!
Variables are set by looking through direct ancestry, rather than through siblings or even SetUp pages. I generally define them either in the environment before running FitNesse or through the FrontPage or the Suite page that contains the tests that need it.
As far as I know, SetUp processes as a part of the page. And I can see why you chose that, but I don't think it is as reliable a location for defining variables as a direct ancestor page.
Additionally, if you are using the COMMAND_PATTERN variable, I'm pretty sure you have to define the variable you want to send to it before you change the COMMAND_PATTERN. And the command pattern cannot be changed multiple times in a single suite execution.

Configure domain name outside the source control

I have a Rails application which I now plan to deploy many instances to different domains. Originally I only intend for it to be on one domain.
I realize that for each domain, I have to replace all the hard-coded values in various places. These include:
asset host path (assets reside on the same domain)
whenever-gem's :application setting (since two domain can share the same server, and this is to avoid crobtab update clash)
some of tasks which uses curl to its own address to trigger events
carrierwave needs a hardcoded value when computing image full url without the request object.
Question
Is there a strategy to set this, so:
the setting should not be commited into source control (like database.yml.example)
Codes outside Rails can access it (whenever-gem does not load Rails environment)
Ways to access the domain can be consistent
One approach you can take is to have a YAML file with per deployment properties. You could even check the development version in and have your deploy scripts overwrite with the correct version.
Typically I'd put that configuration file in shared/config (assuming a capistrano style layout) and then symlink it into the current release during the deploy.

Resources