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
The current architecture of homu is that we only track a single run state, which is modified by a single boolean try_ on the pull request. That means that the run state is either the run state of a build run OR the run state of a try run.
This is the same decision that makes things like #47 happen. In between a try run starting and ending, the try_ flag gets flipped from true to false, so the homu interprets the run result as a build run result instead of try run result.
It affects us here because trying after approval will mean we need to set the try_ bit back on, and homu will get all confused if it then starts a build run. That's why #3 was fixed.
In the future, we can move toward storing a separate production state and try state, so that these runs can happen in parallel without confusing the pull request state. I plan on including that change in #45 (whenever I can find the time to get back around to it).
Currently, once a pull request has been approved
r+
, it can not be tried.There are times when we want to do a timer run, even after
r+
ing the merge request, so it would be great if we could still@bors try
after approval.cc @Centril
The text was updated successfully, but these errors were encountered: