Skip to content
This repository has been archived by the owner on Jul 23, 2024. It is now read-only.

Workflow: Properties annotation #199

Merged
merged 3 commits into from
Apr 5, 2023

Conversation

eloycoto
Copy link
Collaborator

@eloycoto eloycoto commented Apr 3, 2023

This commit introduces a new way to annotate workflow metadata to the workflow itself, the annotation comes with a single option, but with the idea to be expanded in the near future

Each workflow now has a way to define a version that is stored in the workflowDefinition.Properties column (JsonB) object. Users may want to determine the version by hand, or using any tool, like the example given using git-commit-id-plugin.

As an example:


@Bean(name = "simpleSequentialWorkFlow" + WorkFlowConstants.INFRASTRUCTURE_WORKFLOW)
@Infrastructure
@WorkFlowProperties(version = "${git.commit.id}")
WorkFlow simpleSequentialWorkFlowTask(@Qualifier("restCallTask") RestAPIWorkFlowTask restCallTask,
        @Qualifier("loggingTask") LoggingWorkFlowTask loggingTask) {

or:


@WorkFlowProperties(version = "v1.0.0")

The version is a string, but maybe we can think on semver here. I'm very open here, but the idea was to use the commit id AFAIK, and not sure if it adds value having in semver object.

The main reason to use Properties is that they can be extended with more fields like: @WorkFlowProperties(version = "v1.0.0", metricName="myAwesomeWorkflow") or some special logic like on_update, on_die, priority_key, labels.

Fix FLPATH-17

Copy link
Contributor

@gabriel-farache gabriel-farache left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nicely done, left a few comments.

And would be good to have some piece of documentation somewhere explaining where to use and how it's working (like you've done in the description of the PR)

Comment on lines +48 to +50
if (version.isEmpty()) {
version = WorkFlowVersionServiceImpl.GetVersionHashForObject(workFlow);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you want to force a version on the workflow? That will be a bit confusing as a user as the default value is empty string on the annotation, I would expect to have a, empty version in the DB.
Maybe the default version should be the git commit sha?

If you want to keep this behaviour with a generated version based on the hash of the object, it would be great to have it documented somewhere

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the hash is something that we agreed on in a previous meeting; it'll be documented in some way.

Copy link
Collaborator

@pkliczewski pkliczewski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor comments, overall looks good

@@ -102,6 +107,32 @@
</dependencies>
<build>
<plugins>
<plugin>
<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use tag if available?


import lombok.Builder;

@Builder
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about generating getter and setter?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about generating getter and setter?
@DaTa has getter and setter

@@ -82,6 +82,7 @@ public ResponseEntity<ProjectResponseDTO> createProject(@Valid @RequestBody Proj
@ApiResponse(responseCode = "401", description = "Unauthorized", content = @Content),
@ApiResponse(responseCode = "403", description = "Forbidden", content = @Content) })
@GetMapping

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this extra line needed?

import com.redhat.parodos.workflow.definition.entity.WorkFlowPropertiesDefinition;
import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about expanding the asterisk?

This commit introduces a new way to annotate workflow metadata to the workflow
itself, the annotation comes with a single option, but with the idea to be
expanded in the near future

Each workflow now has a way to define a version that is stored in the
workflowDefinition.Properties column (JsonB) object. Users may want to determine the
version by hand, or using any tool, like the example given using
git-commit-id-plugin.

As an example:

```

@bean(name = "simpleSequentialWorkFlow" + WorkFlowConstants.INFRASTRUCTURE_WORKFLOW)
@infrastructure
@WorkFlowProperties(version = "${git.commit.id}")
WorkFlow simpleSequentialWorkFlowTask(@qualifier("restCallTask") RestAPIWorkFlowTask restCallTask,
        @qualifier("loggingTask") LoggingWorkFlowTask loggingTask) {
```

or:

```

@WorkFlowProperties(version = "v1.0.0")
```

The version is a string, but maybe we can think on semver here. I'm very open
here, but the idea was to use the commit id AFAIK, and not sure if it adds value
having in semver object.

The main reason to use Properties is that they can be extended with more fields
like: `@WorkFlowProperties(version = "v1.0.0", metricName="myAwesomeWorkflow")`
or some special logic like on_update, on_die, priority_key, labels.

Fix FLPATH-17

Signed-off-by: Eloy Coto <eloy.coto@acalustra.com>
Signed-off-by: Eloy Coto <eloy.coto@acalustra.com>
Signed-off-by: Eloy Coto <eloy.coto@acalustra.com>
Copy link
Collaborator

@pkliczewski pkliczewski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@lshannon
Copy link
Contributor

lshannon commented Apr 5, 2023

/approve

@pkliczewski
Copy link
Collaborator

@eloycoto please rebase. Tide is complaining :)

public class WorkFlowPropertiesDefinition {

@Getter
@Setter
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DaTa has getter&setter, no need to add them here for each property again

@@ -33,6 +33,11 @@
@Slf4j
public class WorkFlowVersionServiceImpl implements WorkFlowVersionService {

public static String GetVersionHashForObject(Object workflowObject) throws IOException {
WorkFlowVersionServiceImpl versionService = new WorkFlowVersionServiceImpl();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to make it a Delegate/Util, try to make the method "getHash" static and remove "implements WorkFlowVersionService".

@openshift-ci
Copy link

openshift-ci bot commented Apr 5, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lshannon, RichardW98

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [RichardW98,lshannon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 3f6667e into parodos-dev:main Apr 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants