Fix #560 - Check if the .spec.flow has changed before building

[ricardozanini]

Description of the change:
Fix #560

Motivation for the change:

Checklist

• Add or Modify a unit test for your change
• Have you verified that tall the tests are passing?

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.

If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

[wmedvede]

I have created a WF, I can see the build as usual.
I have changed the WF definition, and executed kubectl apply -f xxxx again.
I can't see a new build.

@ricardozanini looks like not working.

[ricardozanini]

@wmedvede That's because we received the .spec.flow already updated in the k8s database. It would only be possible to determine if a workflow would change. I am not sure why the first version worked on my minikube.

Now, I've added a CRC field in the status, so we know if the flow has changed since we control the status update, not the user.

[wmedvede]

I have executed the following sequence:

1. I deployed a workflow, the build_1 is produced, the workflow pod is started, etc.
2. I did a breaking change in the workflow, and kubectl apply -f bla bla (I can see the new CRC generated)
3. A new build_2 is stated as expected
4. the new build_2 fails as expeced (see 2)
5. I fixed the workflow, and did kubectl apply -f bla bla
6. I can see the new CRC was generated, however no new build was started
7. I do more changes in the workflow, kubectl apply bla bla bla again
8. I can see the new CRC is generated

However, since the build_2, no new build is produced.
Not good.

[ricardozanini]

@wmedvede, can you share the SonataFlow YAML for each change you made?

I'm just wondering if this behavior happened before this PR, so the bug might be somewhere else in the states_preview algorithm.

[wmedvede]

@wmedvede, can you share the SonataFlow YAML for each change you made?

I'm just wondering if this behavior happened before this PR, so the bug might be somewhere else in the states_preview algorithm.

I believe the issue us reproducible for whatever workflow, but you can use this use case:

https://github.com/flows-examples/techpreview2/blob/7103145b9c7917c31991e03607c52a0615348ec6/platforms/openshift-dataindex_and_jobservice_as_platform_service_and_global_persistence_postgresql/Readme.txt

Install the platform as pointed out, and then deploy the callback state timeouts.

https://github.com/flows-examples/techpreview2/blob/7103145b9c7917c31991e03607c52a0615348ec6/platforms/openshift-dataindex_and_jobservice_as_platform_service_and_global_persistence_postgresql/04-sonataflow_callbackstatetimeouts.sw.yaml

1. The first deploy will work
2. To force the second build, basically change:

  flow:
    start: PrintStartMessage

to the value

  flow:
    start: PrintStartMessage2

The second build will start, but will fail. Since the sate definition wasn't changed.

3. For the third build, keep:

  flow:
    start: PrintStartMessage2

and go to the workflows states, and change the name of the state also there:

    states:
      - name: PrintStartMessage2
        type: operation
        actions:

This time, a potential new build should be good.
However, it's never produced.

p.s. the workflow DB is initialized automatically, no need to do a manual initialization

[ricardozanini]

@wmedvede rebased!