At the completion of this section, you will:
...
Configure the File saveArtifacts operation by adding it to the center pane and the plugin will open for additional configuration. The saveArtifacts operation is used to save files from the workflow temp folder into the FlexDeploy Artifacts Repository. At the successful completion of the workflow, the cloned property file will automatically be pulled back to the artifact repository. Select OK
- All plugin inputs can be a literal value, or a Groovy expression. Click the T icon to change the input to Groovy
- This is the Variable Lookup button, clicking this will open a window to help find variables to use in the Groovy expression
- Start typing a variable name in this box, and select the variable name we want to use. We're using
FDBLD_GIT_SOURCE1_SPARSE_CHECKOUT_FOLDERS. - After selecting the variable, press Copy and Return to copy the variable name and close the popup
- Paste the variable in the Groovy input box
- A filter for selecting which files are saved into the artifact repository
...
We will use the WebLogic createOrUpdateWeblogicConfig operation to deploy the configurations. The plugin will contact the WebLogic server to create datasources, JMS modulesobjects, and EIS entries defined in the properties files we will check file checked out with the build workflow. Configure the operation by adding it to the center pane and the plugin will open for additional configuration. We do not need to enter anything for the Properties File Path input, because the operation will automatically default to look in the artifact repository directory for the properties files saved by the build workflow. Below the Inputs section, we can see the Outputs section. Here we can assign data coming back from the plugin execution to workflow variables for use later in the workflow. These are usually used in more complex workflows, so we won't be using them in this tutorial.
...
Now that the workflow is built, we will define any Workflow Properties we want to use. These properties will be replaced in the properties files file we check out from Git. This allows us to use a single properties property file and change it for each environment, rather than having multiple files for every environment. Using these properties inside of the properties files also allows us to build the project once, then deploy those files to each environment without having to build again.
...