I tried creating 3 distinct workloads at each layer.  This was done by writing ngnix deployments, each unique, under 03_services dir for ./site/, ./profile/, and ./base, and appending them to their respective kustomize.yaml resource lists, and finally pushing them to the remote repo.  Executing apply_workloads showed that only new deployments from base and profile were created, but site was not.

The issue lies in the way DownloadRepos() and ApplyWorkloads manages relationships between the separate layers (base, profile, site). The process:

1. Downloads the remote blueprint to ~/.kni/$SITE/blueprint
2. Copies the local (stale) site ~/.kni/$SITE/site => ~/.kni/$SITE/blueprint/sites/site
3. Walks ~/.kni/$SITE/blueprint/sites/site to replace git urls with relative paths (separately, this seem erroneous b/c the paths have already been replaced in the stale source, but I don't know what's doing it yet)
4. Applies kustomize to ~/.kni/$SITE/blueprint/sites/site (still stale)

So the issue is that it downloads the remote files, but executes against a copy of the locally stored, stale site. The relative paths point the stale site to the new versions of the profile and base. Thus any changes in ~/.kni/blueprint/sites/$SITE (the remote version), are ignored.

I've been unable to reproduce the behavior via:

1. Spin up a management cluster (https://github.com/copejon/blueprint-management-hub)
2. Apply workloads
3. Update blueprint components under edge-mgmt-hub.gcp.devcluster.openshift.com/blueprint/base/03_services/... and push to above repo
4. Apply workloads again
5. Check local ~/.kni copy of blueprints.  In my case, shows the changes made in remote.

 
Is this the process you've used to reproduce the behavior? If not, please let me know.