[WFCORE-6893] Add channel manifest versions information to the installer history and product-info operations #6583
Conversation
yersan
force-pushed
the
WFCORE-6893
branch
2 times, most recently
from
ed2cb87 to
25a5b1b
Compare
…-info Signed-off-by: Yeray Borges <[email protected]>
Signed-off-by: Yeray Borges <[email protected]>
…ion returns expected manifest versions Signed-off-by: Yeray Borges <[email protected]>
…tCase Signed-off-by: Yeray Borges <[email protected]>
… :product info contains expected manifest versions in domain mode Signed-off-by: Yeray Borges <[email protected]>
…t class to handle the common code Signed-off-by: Yeray Borges <[email protected]>
|
Core -> WildFly Preview Integration Build 14935 outcome was UNKNOWN using a merge of a1213db |
|
Core -> Full Integration (with SecurityManager) Build 15128 outcome was UNKNOWN using a merge of a1213db |
|
Core -> Full Integration Build 14804 outcome was UNKNOWN using a merge of a1213db |
|
Core -> Full Integration (with SecurityManager) Build 15129 outcome was UNKNOWN using a merge of a1213db |
|
Core -> Full Integration Build 14805 outcome was UNKNOWN using a merge of a1213db |
|
Core -> WildFly Preview Integration Build 14936 outcome was UNKNOWN using a merge of a1213db |
| } | ||
| } | ||
| }, OperationContext.Stage.RUNTIME); | ||
| }, OperationContext.Stage.RUNTIME, true); |
There was a problem hiding this comment.
@bstansberry just wanted to highlight this change, it makes it work, but somehow conceptually could be wrong.
Notice that we need it to allow this runtime step to be executed before from the InstallationReportHandler.java
execution.
I think it is ok, since there should not be other handlers that would require a specific order of execution of this step, but, well, in case you know a better way to do it.
I would have expected that the addfirst flag in the step that adds the execution of the history operation at InstallationReportHandler.java handler would have worked, but it doesn't. I'm not sure yet why.
There was a problem hiding this comment.
The real problem is that the InstMgrHistoryHandler.java adds its own runtime step, so trying to add the outer first from InstallationReportHandler.java does not take effect at all.
What would be the proper way to address this situation? I can think of adding it as a new step inside InstMgrHistoryHandler if the current stage is not RUNTIME, and if it is RUNTIME just execute it without adding a new RUNTIME step, but not sure.
Let it be as it is now seems OK, but again, conceptually, it does not look correct
2 participants
Jira issue: https://issues.redhat.com/browse/WFCORE-6893