Feature Request: PR Pipeline Should Sync New Items in Manifest from Target Branch

[ralphcallaway]

Scenario (intentionally simplified for demonstration purposes)

• master branch just has apex classes
• you create a feature branch for some new apex
• to get it working right you need to alter an workflow field update, which you add to the manifest

Current Behavior
field update would get deployed as if it's new, which gets the job done functionally, but we lose the history of that component, and can't tell what is was before, and what part got modified, which is very useful in a rollback, or forensic analysis of why something is in a particular state

Workaround
before merging the feature branch, update the manifest in master, current sync and merge will take care of everything

Ideal Behavior
before merging the feature branch, incorporate new components (to the manifest, not necessarily the org) into master prior to performing the sync

Discussion
kind of tricky, we'd want to ensure

1. manifest changes and the files they reference only get into master if the merge succeeds
2. need to merge the manifest changes from feature into master, not just overwrite (i.e. can't just do git checkout feature -- manifest/package.xml which just overwrites)
3. we need to consider stuff getting added or removed from the manifest
4. we might need to deal with fact git xml merge isn't smart enough and do something specific to the manifest format (not covered in example)

Rough Attempt
Very likely there are things missing, bugs, and opportunities for simplification, but shows the concept

# 1. master_sync.sh
same as sync.sh

# 2. manifest_sync.sh
git checkout -b temp_feature master # temp master to stage merge 
git merge $BITBUCKET_BRANCH # merge the feature
git checkout -b master_with_manifest master # create sync branch
git checkout temp_master -- manifest/package.xml # pull merged manifest into sync branch
sfdx force:source:clean -n
git commit -am "[skip ci] Auto-Pull of Production with $BITBUCKET_BRANCH manifest" || echo "No changes to commit"
# no push, it'll get incorporated when the merge happens, and no need to create any branches we'll just have to delete later

# 3. package.sh
git checkout $BITBUCKET_BRANCH
git merge temp_master
sfdx git:package -d dist/$BITBUCKET_BRANCH -s $BITBUCKET_BRANCH --purge

# 4. merge.sh
no changes

[ChuckJonas]

field update would get deployed as if it's new, which gets the job done functionally, but we lose the history of that component,

I wouldn't say we "lose history of that component", because we were never tracking it in the first place.

IMO, simplest and best solution to this issue is just to expand the metadata that we are tracking. The only downside of tracking more MD is that the production sync will take longer... however, if we can figure out #3, it won't be an issue.