A more opinionated flavor of Lightning for building decoupled applications. Support ended on November 2, 2021 and this project is no longer maintained.
This seems like a problem with Lightning itself, but filing here because this is where it manifests itself.
Take, for example, the 1.1.0-alpha2 update matrix. Headless Lightning 1.1.0-alpha2 pinned to Lightning 2.2.3. But when the build script restores that database and runs lightning updates, it runs updates from back in Lightning 2.2.1. You can see an example here:
https://travis-ci.org/balsama/headless-lightning/jobs/311637618#L1201
This causes a more severe problem for HEAD because Lightning Workflow Update 2.2.1 makes references to Workbench Moderation, which doesn't exist.
So I guess the question is how does Lightning Update determine which updates to run? I think we've avoided this problem on Lightning itself because our build instruction call robo which passes a --since option.
This seems like a problem with Lightning itself, but filing here because this is where it manifests itself.
Take, for example, the 1.1.0-alpha2 update matrix. Headless Lightning 1.1.0-alpha2 pinned to Lightning 2.2.3. But when the build script restores that database and runs lightning updates, it runs updates from back in Lightning 2.2.1. You can see an example here: https://travis-ci.org/balsama/headless-lightning/jobs/311637618#L1201
This causes a more severe problem for HEAD because Lightning Workflow Update 2.2.1 makes references to Workbench Moderation, which doesn't exist.
So I guess the question is how does Lightning Update determine which updates to run? I think we've avoided this problem on Lightning itself because our build instruction call robo which passes a --since option.
@phenaproxima we can discuss in the AM.