I'm wondering what the best way to use CumulusCI is to deploy changes that managed package upgrades usually skip. The common problem areas are:
- Picklist values
We package daily and there is a lot of change at present.
My first thought is to have a folder containing a copy of the changed metadata for each version:
upgrades/v2.160/flexipages/... upgrades/v2.160/layouts/... upgrades/v2.161/flexipages/... upgrades/v2.161/layouts/... upgrades/v2.162/flexipages/... upgrades/v2.162/layouts/...
with older versions discarded after a few weeks. (Though automating the checkout of each version from Git and only varying which metadata files are deployed could be a better approach.)
So to go from 2.159 to 2.162 all 3 of the above would be deployed whereas to go from 2.161 to 2.162 only the last one would need to be deployed.
But from a scan over the CumulusCI documentation and Trailheads I don't think this pattern fits easily? Brute force might be:
upgrade_to_v2.163: steps: 1: options: path: upgrades/v2.163 task: deploy upgrade_to_v2.164: steps: 1: options: path: upgrades/v2.164 task: deploy upgrade_to_v2.165: steps: 1: options: path: upgrades/v2.165 task: deploy
What is the best way to do this sort of incremental upgrading from version to version?
(Having a way to signal that there is a local change that would be lost would also be useful.)
I'm now thinking this is probably better handled in GitHub Actions where I want to checkout a tag or hash and then for that tag or hash run a series of
sfdx force:source:deploy -p filepath ideally taken from e.g. a JSON file.