Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Is there away to import an entire file of values into a deployment process?
-
We have to deploy multiple instances, a lot of them, and we normally deal with the settings via a xml file with all the settings for the individual deployments.
Is there someway to do a mass import of values from a XML file to set variables to be used in a job?
Or a way to import Java property file types?
Or pull them from a database?I know there is the import value from file but frankly that is sort of useless when you have a file with several hundred settings in it.
Thanks,
JonProduct: BuildMaster
Version: 4.8.6 -
This can be done, but it would require a custom action... basically you'd read the file and call the StoredProcs.Variables_CreateOrUpdateVariableDefinition API method with whatever context arguments you would like, i.e. execution ID which can be pulled from the action's Context.ExecutionId property.
-
Thanks for that info.
Would doing that at the beginning of a Deployment allow access to those variables throughout the rest of that deployment?So say first step is read the config and set the variables as you stated and then proceed with next action.
Thanks,
Jon -
Yes, specifically it will persist for the duration of the execution. Note that specifying additional context info (i.e. appId, release number, build number) will actually change the type of the variable since it's inferred from the context, so make sure to only supply the execution ID to the API method.
-
So if I understand this correctly I need to write a small program to extend BuildMaster because it doesn't have a way to handle dynamic properties from an external source?
Is there a better method of using Buildmaster where you need to install an application multiple times, like 100+, all with slightly different configurations? These are not web apps.
-
You can put variables on most entities, like applications, servers, environments, etc. These then get cascaded at runtime, so the idea is that you can run the same deployment plan in multiple contexts
I'm not sure what you mean by "install an application multiple times, like 100+, all with slightly different configurations".
One common thing we see is the "quasi-custom software" pattern, wherein you have a core application with tweaks (big, small, or config only) that get deployed to various customers at various times (or all at the same time).
The general strategy for this is to have one application per customer that all use imported deployables from the other applications. You can then share deployment plans between the "customer" applications so they all work the same, apply tweaks as needed, and then just deploy on the customer schedule.
-
back to using the API.
You said to be careful what I pass so just to be sure I do this correctly. I would pass in the Execution Id and then also give the Variable Name and Value Text and that should give me those for that particular execution? Don't even give the other fields at all in the API call? -
Yes, that's correct; if your doing this with a custom extension, then you can use the "StoredProcs.Variables_CreateOrUpdateVariableDefinition" method directly, and pass null in where appropriate.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login