Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add "duplicateFilter" on deployment #1159

Closed
berndruecker opened this issue Aug 8, 2018 · 5 comments · Fixed by #2635
Closed

Add "duplicateFilter" on deployment #1159

berndruecker opened this issue Aug 8, 2018 · 5 comments · Fixed by #2635
Assignees
@miguelpires
Labels
kind/feature Categorizes an issue or PR as a feature, i.e. new behavior scope/broker Marks an issue or PR to appear in the broker section of the changelog scope/clients-go Marks an issue or PR to appear in the Go client section of the changelog scope/clients-java Marks an issue or PR to appear in the Java client section of the changelog

Comments

@berndruecker
Copy link
Member

Add some duplicate filtering like in Camunda BPM (e.g. https://docs.camunda.org/manual/7.9/user-guide/spring-framework-integration/deployment/) to allow for services to auto-deploy their owned processes at startup. Currently this leads to multiple versions being deployed or requires a manual deployment step.
@berndruecker
Copy link
Member Author

Should probably get easier with the current RocksDB refactoring? Would be an awesome feature to get

@jwulf
Copy link
Member

jwulf commented May 28, 2019 •
edited
Loading

At the moment this is implemented in the Node.js client library - deployWorkflow(filename, { redeploy: false }) will not deploy the workflow if it is already on the broker. This uses the listWorkflows gRPC method and compares based on the process id, so it doesn't compare the XML - only the presence or absence of a workflow with the process id.

In the current snapshot we have removed listWorkflows during the atomix refactoring so this client-side convenience will no longer work.

It is useful for programming clients that bootstrap the broker with the workflows, and it would be good to have this built-in to the broker (or keep listWorkflows available for this client-side workaround).

@menski menski added scope/broker Marks an issue or PR to appear in the broker section of the changelog scope/clients-java Marks an issue or PR to appear in the Java client section of the changelog scope/clients-go Marks an issue or PR to appear in the Go client section of the changelog Status: Ready kind/feature Categorizes an issue or PR as a feature, i.e. new behavior labels Jun 11, 2019
@menski
Copy link
Contributor

menski commented Jun 11, 2019

REST API docs for camunda deploy command https://docs.camunda.org/manual/7.11/reference/rest/deployment/post-deployment/

@miguelpires
Copy link
Contributor

For documentation purposes, I'll note down some decisions (and their reasoning) that were made about this feature:

  • The filtering will check the deployed resources against their latest version and not against every version - this is more efficient and also makes it simpler in situations where the user rolls back to a previous a workflow (the "working" workflow is the always the latest)
  • Duplicate filtering will be the default behavior - this seems like a benefit for most use cases; if this becomes an issue, a parameter can be easily added later without breaking backwards compatibility
  • There will not be a parameter in the clients to toggle this feature on/off - the use cases where duplicate filtering might be problem are very specific and currently don't pose a problem; additionally, not having it makes this feature much smaller

@miguelpires miguelpires mentioned this issue Jun 15, 2019
Merged
ghost pushed a commit that referenced this issue Jun 19, 2019
Merge #2635 #2657
5fc9df2 
2635: feat(broker): filter duplicated deployments r=MiguelPires a=MiguelPires

The filtering was implemented using checksums because although a byte-by-byte comparison would work for XML resources, it wouldn't for YAML resources since we convert them to XML before storing. Since another approach was required for the YAML resources, it made sense to be consistent and have a single implementation for all resource types.

closes #1159 

2657: chore(protocol): rework WorkflowInstanceCreationRecordValue r=MiguelPires a=MiguelPires

closes #2629 


Co-authored-by: Miguel Pires <[email protected]>
@ghost ghost closed this as completed in #2635 Jun 19, 2019
@jwulf jwulf mentioned this issue Jun 19, 2019
Merged
@berndruecker
Copy link
Member Author

Great!

@miguelpires miguelpires mentioned this issue Aug 10, 2020
Closed
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@miguelpires miguelpires

Labels
kind/feature Categorizes an issue or PR as a feature, i.e. new behavior scope/broker Marks an issue or PR to appear in the broker section of the changelog scope/clients-go Marks an issue or PR to appear in the Go client section of the changelog scope/clients-java Marks an issue or PR to appear in the Java client section of the changelog
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(broker): filter duplicated deployments camunda/camunda
5 participants
@jwulf @menski @berndruecker @miguelpires @KerstinHebel