I am in the process of putting a project on Octopus deploy. There are a lot of Json variables that need to be changed depending on the environment.
In particular, I need to change many "path" variables that point to a shared drive. For debugging and UAT I want to change all these to a local path.
Eg: 10 Json objects with a value "path": "sharedDrive\uniquePath\\..." changed to "path": "C:\\uniquePath\\..."
Is this possible with Octopus deploy?
Related
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 have created a local windows filepath that is dynamic based on the user.
C:\Users\%USERPROFILE%\rest_of_filepath
This path works perfectly on my local machine, but when I email it to someone else, they get this error:
We can't find 'C:\Users\%USERPROFILE%\rest_of_path'. Please make sure you are suing the correct location or web address.
How to I get it to work for the others I am sending it to?
The USERPROFILE is the the correct Environment Variable to use to retrieve the path of the Windows user profile folder. This will work even if the folder is in a "non-default" location. Windows created this Environment Variable for this exact reason. Encasing a word in % informs Windows that the word inside the % is an Environment Variable. Windows therefore knows to replace the entire '%USERPROFILE%' with the path associated to that variable.
In the case of the question the path C:\Users\%USERPROFILE%\rest_of_filepath is used. The C:\Users\ portion of this path is unnecessary and results in C:\Users\C:\Users\<userprofilefolder>\rest_of_path since the Environment Variable will also retrieve that portion of the path.
%USERPROFILE\rest_of_path is all that is needed.
Ultimately, even if the HTML interpreter in the email client was able to parse Environment Variables, access to local system files from email is not allowed for security reasons.
Emailing the path and instructing the recipient to copy and paste the it into the Windows file explorer is the recommended work-around.
src: Recognized Environment Variables that are recognized only in the user context
In BW6 profile files(.substvar) we need to use substitution parameter which will be replaced by CI-CD platform just before deploy to any environment,
for example if we have three environment : dev, test, production, for those environments we have a sftp access, will have three profile files for each environment, developper will need to put values like this in profiles so the CI-CD platform replace them as needed for each environment :
My problem is with non string property, for example integer or password, how to deal with them because for example can't use #port# in an integer field using business studio, when we open as xml it works normally but in business studio can't set it.
Any best practice to deal with this ?
If you click on the value, you should see a "config" icon. Click on Container Configuration:
Once you click on it, the field will convert to "String" and you can enter the name of the variable:
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 have some Windows Server 2016 instances on GCE (for Jenkins agents).
I'm wondering what is the best/good practice when it comes to computer name.
Currently, when I want to create a new node, I clone an instance (create images from disks + create template + create instance from template).
On this clone, I change the computer name (in Windows) so that it has the same name as on GCE. Is it useful? recommended? bad? needed?
I know that the name of the Jenkins node needs to be the same as the name of the GCE instance (to be picked up easily). However, I don't think the Windows computer name matters.
So, should I pick an identical generic name for all of them? A prefix+random generated name? Continue with the instance=computer=node name?
The node name that I use in Jenkins is always retrieved from env.NODE_NAME (when needed), so that should not break any pipeline. Not sure thought, as I may be missing something (internal to Jenkins).
Bonus question: After cloning, I have to do some modifications on the clone for Perforce (p4) to work.
I temporarily set some env variables
I duplicate the workspace: p4 client -t prefix-buildX-suffix prefix-buildY-suffix
I setup the stream (not sure if doable in one step)
Then regenerate the list of files: p4 sync -k <root_folder_to_be_generated>/...#YYYY/MM/DD
So, here also there's a name prefix-buildY-suffix which is the same as the one from the instance=computer=node (buildY). It may be a separate question, but as it's still from the same context, I'm putting it here: should I recreate a new workspace all the time? Knowing that it's on several machines, I'd say yes. Otherwise, I "imagine" that p4 would have contradictory information about the state of this workspace. So, here also, I currently need to customize the name. So, even if I make the Windows computer name generic, I would still need to customize the p4 workspace name, wouldn't I?
Jenkins must have the same computer name as the one on the network.
So, all three names must be identical.