Throw error to force error status in workflow UI

[gabriel-farache]

FLPATH-1127
https://issues.redhat.com/browse/FLPATH-1127

Currently, when an error occurs in the workflows, their status in the UI is completed which is not really a good feedback; it should be error instead to reflect the real state of the workflow.

We can hack it, based on https://github.com/tiagodolphine/backstage-orchestrator-workflows/blob/main/workflows/wait-or-error.sw.yaml, to throw an error, if something is wrong in the workflow, in order to force the status to error and better reflects the real state of the workflow

[rgolangh]

We can expect the kogito runtime to mark the process instance as failed when this is resolved apache/incubator-kie-kogito-runtimes#3475

[rgolangh]

this would mean we would need a slight definition change to make that happen

states:
  name: endWithError
  metadata:
     errorMessage: '.somekey'
  end: true

[gabriel-farache]

@rgolangh With apache/incubator-kie-kogito-runtimes#3475 / apache/incubator-kie-kogito-runtimes#3491 it works
I had to use the latest swf nightly builder image to be able to use the feature, hence updating the DEV dockerfile to latest and using matching quarkus extensions

But I guess we do not want to merge that until we have the fix available in stable build (cc @pkliczewski @masayag ), maybe @ricardozanini knows when this fix will be embedded

[masayag]

As stated, let's merge after there is an available stable build with the required enhancement.

[pkliczewski]

@gabriel-farache apache/incubator-kie-kogito-runtimes#3475 was fixed and now we can set workflow end status

[gabriel-farache]

@gabriel-farache apache/incubator-kie-kogito-runtimes#3475 was fixed and now we can set workflow end status

@pkliczewski Yes, I know, that is what I wrote in my previous comment.
But fixed does not mean it's on a stable release of the swf-builder: latest is more than 4 month, CR1 dates back from 15th of April whereas the issue was merged ~3rd of May

[pkliczewski]

@gabriel-farache there is new stable build release 2 days ago and @masayag will create stable branch soon and use this build. I think we have everything we need to use it.

[rgolangh]

@gabriel-farache can you resume this work?

[masayag]

according to the security recommendations, it isn't advised to use the latest.

[gabriel-farache]

agree but this is the only image with the feature in it: apache/incubator-kie-kogito-runtimes#3491 was merged on may 3rd but the most recent image with a fixed tag dates from April 28th

[gabriel-farache]

And same goes for https://quay.io/repository/kiegroup/kogito-swf-builder?tab=tags&tag=latest

[gabriel-farache]

@rgolangh We should close it IMO, completion and error are related to the workflow runtime execution, not the status of what the workflow is doing
There should be a separated status for that, I think there was some issue/discussion about that but I can't recall.

Plus, Gary stated in his latest comment https://issues.redhat.com/browse/FLPATH-1127 that it's fine

[gabriel-farache]

nevermind my above comment, it appears that I made some change based on apache/incubator-kie-kogito-runtimes#3475 that I completly forgot about and that this is the baseline to manage workflow "purpose" failure

[gabriel-farache]

@rgolangh

@gabriel-farache can you resume this work?

I only need a swf builder image with a fixed tag

[masayag]

latest isn't recommended by konflux, let's pin to a specific version

[gabriel-farache]

yes but this is for dev and IMO, for dev purposes it's OK to use the latest to test changes, no?

[masayag]

Somehow I remembered that konflux has no-latest-tag tolerance. if that isn't the case, that's fine.
but giving it another thought - we won't be able to know against which builder image the workflow was created.
that should provide us some information when debugging issues or when trying to reproduce one.

[gabriel-farache]

that should provide us some information when debugging issues or when trying to reproduce one.

the dev image should only be used when developing something on the workflow, so that does no apply here

we won't be able to know against which builder image the workflow was created.

When someone is developing (s)he knows what's going on

[rgolangh]

I don't mind chaning that dockedrfile, it is not in use by konflux or the the github action. Just looking more closely I see that there is no meaningful difference to the workflow-builder.Dockerfile other than the builder image. In that case why not remove this file altogether and use a build-arg if you want some latest? or even create a make rule for building for devlopers?

[masayag]

There used to be differences between the two. If this is no longer the case (when we had the extensions included in the build image of the d/s builder image).
Wouldn't the developer will need to have a dockerfile, even with argfile? where do you recommend to have that file for him? (talking about upstream contributor/developer)

[rgolangh]

can you please rephrase the cover message for the PR?

[rgolangh]

can you add an MTA e2e test that will test this failure mode?