DevOps Automation

 View Only

UrbanCode Deploy 10 Minute Tip : Property Scopes – Do you know them all?

By IBM DevOps Expert posted Fri May 06, 2022 01:58 PM

  



Do you know all of the scope modifiers we can use to reference UCD properties?

IBM UrbanCode Deploy (now IBM DevOps Deploy) has a construct that we can use in many places to substitute the name of a property for its value.  So we can use an expression like ${p:propertyName} or the alternate give me its value if there is such a property ${p?:propertyName}.

We can extend either form to allow us to say in what scope the property should be looked for.  The expression then looks like ${p:scope/propertyName} or ${p?:scope/propertyName}.

The well-known scopes being:

  • application
  • component
  • environment
  • resource
  • version

There are some other perhaps less well-known:

  • system
  • agent and the specialised iteration scope in for each agent contexts of an application process
  • process

There is also the special property allProperties that returns a comma-separated list of property name/values that you will probably have seen in steps such as Replace Tokens or Install Template.

But there are also other scopes.  Step properties are often overlooked, they allow you to reference a property created by an earlier step in the current process.  In this case, the scope is the name of the prior step.

Something like ${p:my step/myProperty}.  Of course, you need a step that exposes properties in this way.  You can see what properties a step reveals in the Input / Output Properties of a process step execution.  The little white document icon.  The plugin documentation on urbancode.com will also list these.

But there are more…

Did you know that a component that has a source code plugin associated with it also exposes its properties?

Yeah that’s right you can go through a scope called component/<<plugin>>/propertyName.  The trick here is in discovering what the value of <<plugin>> is.  An easy way to discover this edit a shell step or some other place that offers property name completion and type ${p:comp at this point a drop-down box should appear showing things like this:



You can now see the scope of the source plugin properties. In this case it’s the subversion plugin and its named SubversionComponentProperties.  So, our property expression would now look something like: ${p:component/SubversionComponentProperties/<<pluginpropertyname>>

If you want to delve into the source code plugin itself, you can also find this information in the plugin.xml file.

Are there more? Of course there are…

The component scope also reveals a couple of other interesting sub-scopes:

  • custom
  • template

To illustrate their use, I set up this little scenario:

  1. Create a Component Template
    1. Under Configuration > Properties create a property called template-property
    2. Under Configuration > Component Property Definitions create a property called template-comp-prop-def
  2. Create a Component and base it on the template you just created
    1. Under Configuration > Properties create a property called component-property.  You should also see the template-property on that screen shown as inherited.
  3. Create a component process with a single shell step with the following in it:
echo "component all properties: ${p:component/allProperties}"
echo "template allproperties: ${p:component/template/allProperties}"
echo "custom all props: ${p:component/custom/allProperties}"

Now set up an application and a resource tree so that you can run this component process.  You should see something like this:

command output: 
component all properties: template-comp-prop-def=a,template-property=b,comp-property=1
template all properties: template-comp-prop-def=a
custom all props: template-property=b,comp-property=1

If we examine this output we can see that:

  1. ${p:component/allProperties} shows us all the properties from both the component and the template.
  2. ${p:component/template/allProperties} shows us only the component property definitions from the template
  3. ${p:component/custom/allProperties} shows us only the basic properties from the component and the template but not the property defs.

If I have a component property with the same name as a template component property definition (not to be recommended of course, but sometimes these things happen when perhaps the template is maintained by another person/group).  My component definition would obscure the template property.  But using ${p:component/template/allProperties} I would see the template property instead of the component one.

In this example, I’ve used allProperties to illustrate but you could also use the actual property names.


#UrbanCodeDeploy
#10minutetip

0 comments
3 views

Permalink