You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
sandbox: add versioning and version history checking #980
See parent issue and lightning implementation for details.
I think the work here is:
Add (fix, update, merge) a version hash algorithm
Add some kind of compare function to Project to compare it to another project
Actually there are two comparisongs:
Are these projects identical? That means: check all the workflows and see if anything is different
Have these projects diverged? That means: check the histories to ensure they have a common root (probably the most recent version in the target is included somewhere in the history of the source)
Are there any top level project props that get counted in versioning?
Use versions to detect whether we can safely checkout another project onto disk
Use versions to tell whether its safe to pull
Note that versions don't give any diffing support: if we want diffing we have to add it explicitly (we should be able to use a similar approach what CLI deploy already uses)
This issue is to add support to Project and all relevant CLI commands (it might need breaking up into an epic)
Right now a Project doesn't have a version. So if you compare two projects and the only difference is that one has added a collection, it'll count as no difference. That means either we need a project version hash, or we need special diffing logic for Projects
The current version hash of the target is NOT present in the version history of the source
Note that Lightning mostly controls version history and the CLI doesn't support it at all yet.
When we implement openfn project fork, the CLI needs to set the initial history of the new fork to be the base version. That gives us a reference point for when we merge later.
Activity
josephjclark commentedon Sep 22, 2025
Right now a Project doesn't have a version. So if you compare two projects and the only difference is that one has added a collection, it'll count as no difference. That means either we need a project version hash, or we need special diffing logic for Projects
josephjclark commentedon Oct 16, 2025
It's a conflict if:
The current version hash of the target is NOT present in the version history of the source
Note that Lightning mostly controls version history and the CLI doesn't support it at all yet.
When we implement
openfn project fork, the CLI needs to set the initial history of the new fork to be the base version. That gives us a reference point for when we merge later.josephjclark commentedon Oct 20, 2025
Return true if the current workflow can be merged into the target workflow without losing any changes.
We ask the SOURCE if it is compatible with the TARGET