New features from PR#54

[engswee]

Hi d-sooter & nimbit-software

To start off our discussion, I'll pick the following points that you mentioned you have changed.

deployment via configuration files with parameter overrides ( allows duplication of iflow with different configurations) this allows us to have a base iflow and make changes there and redeploy different instances with different configs.

Is this different from passing in different manifest and parameters files using --file-manifest and --file-param flags in the update artifact command?
Following is an Azure Pipeline example of the usage
https://github.com/engswee/flashpipe-demo/blob/7c0952ff8bdcd98e9733042b74bef2fbe2df5bfd/azure-pipelines.yml#L93C16-L94C124

ability to be able to pass in just a config file to the cli (yaml). This allows us to not have to pass everything via cli but rather just reference a config file.

This is already available as it is built into the Viper capability that FlashPipe uses. It's mentioned in the CLI documentation, but probably not very obvious.

[adajohdaf]

Hi

Regarding duplicate iflows this is what I do:
A bash script with common functions:

update() {
  local env="$1"
  local artifact="$2"
  echo "Updating artifact '$artifact' in environment '$env'"

  flashpipe update artifact \
    --package-id "Company${env}" \
    --dir-artifact "./artifacts/${artifact}_ISD" \
    --artifact-id "${artifact}_${env}" \
    --file-param "./parameters/${artifact}_${env}.prop" \
    --file-manifest "./parameters/${artifact}_${env}.MF"
}

Then in another script I can:

# Source functions
source "$(dirname "$0")/flashpipe-functions.sh"

### ISD env. ###
update "ISD" "Inbound_message"

This allows me to deploy the same iflow multiple times with different names and parameters in the same tenant.