Separating proxy and config deployment using maven plugin

[berendvanwaalwi]

The CICD pipeline we use, uses the maven apigee plugin to deploy configs, proxies and shared flows. As per the folder structure, the edge.json (configs) is in the same repo as the proxy.

we make a push to scm. This triggers the pipeline which goes through both plugins. The one for config and the one for proxy.

My question/problem is as follows: How to only deploy configs when a change is made to them without running the proxy deployment (or vice versa)? We can of course do diff checks in git, but is there an easy solution to this?

[sidd-harth]

The difference between Config and Proxy deployement is the addition of prepare-package, package and deploy phases in shared-pom.xml.

Maybe we can create a couple of profiles with special activation conditions to deploy only config or both config & proxy.

Note - I guess it should work, but I have not tried it yet.

[kurtkanaskie · Accepted solution]

Hi @Berend van Waalwijk, great question!

As I see it, you have 2 options:

1. Create a separate repo for your config items as described in the EdgeConfig sample in https://github.com/apigee/apigee-config-maven-plugin. Probably overkill for typical proxy config items.
2. Use a script to detect changes to edge.json or resources directory and set env variable to be used on the mvn build command.

For option 2, I used this script to detect changes on the last commit.

#! /bin/bash

ConfigChanges=`git diff --name-only HEAD HEAD~1 | grep "edge.json"`
if [[ $? -eq 0 ]]
then
	export EdgeConfigOptions="update"
else
	export EdgeConfigOptions="none"
fi

# Redirect output from this script to an "edge.properties" file in Jenkins. 
echo EdgeConfigOptions=$EdgeConfigOptions

Then, in Jenkins inject the env variables and use them on the mvn command.

Thanks for the question, this makes for a nice addition to my best practices!

[berendvanwaalwi]

Thanks a lot Kurt. This answers my question as for the option being there in built in the plugin. More thanks for the provided script. We'll implement this in our groovy script on which the pipeline runs.