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 }}
This repository has been archived by the owner on Nov 16, 2021. It is now read-only.
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.
The text was updated successfully, but these errors were encountered: