Fine-grained commit-level propagation based on git packages history

[davidferlay]

Current

• Currently packages are mostly used with git repos + git tags
• This has the effect that --sync propagation compares artifacts which are checked out on tags and thus cannot propagate versions in the successive order of changes made in packages
• This is functionnaly viable but some insight is lost in the process: "which change impacted each components and how, either by a direct change or by a propagated version"

Expected

• Propagating successively each commit of packages when comparing artifacts would be useful for versions to to have more meaning

packages should bring full git history

when we discover list of resources to propagate, need to crawl
- 1. platform source code
- 2. packages
to define which versions are prioritized (using git history of bumps))

and it will be mandatory for package to have git inside
unless we fallback to default behavior, to support both cases.
If we can't determine when version was added -> fallback to current bump --sync behavior

[davidferlay]

Also implementing git history parsing will fix a possible issue with propagation of variables value changes:

Example:

• 1. change variable X, content Y - commit, bump - got hash X
• 2. change variable X, content Y1 - commit, bump - got hash Y
• 3. change variable X, content Y (back to original) - commit, bump - got hash X <<< same as X

for variables change, rule is the same as for resources, but variables hash prevails over parents, meaning that in that case, resource will revert to same version as earlier, which will tell system to use existing image mamtching earlier version:

• if only change is rollback of var value > then it makes sense for system to use image that already exist with that state
• but if changes contain also some other changes, var value propagation will prevail and "mask" that another change was added and actually requires building of a new image

To fix that case it makes sense to follow the "parsing git history" to do propagation successively

[iignatevich]

for compose, need to add the way to identify from which place packaged was taken and store it. So next command, like bump --sync will have access to it and can properly propagate versions.