We need to mimic a similar pattern as we do internally for versioning shared workflows. This way we don't run into the chicken & egg scenario.
Example of where we have to update tests repo to also test changes along with the other repos workflow.
https://github.com/opentdf/tests/pull/185/files#diff-e45b4e0da069e1fbfec93f1c7d808b40e8b374adaada7c22d42e434b78b652f8R35
Failing workflow: opentdf/java-sdk#154
Process should be
- Create branch in tests repo
- Point repo that is failing to working branch
- Once workflow has passed successfully merge workflow changes to main
- Changes to main should trigger a new release. This gives us the ability to reference the workflow via
v1 in calling repos
This process is similar to what we do internally. Follow up with @el-virt for any questions.
Acceptance Criteria:
- All calling workflows reference
v1
- Changes merge to main cut a new 1.x release
We need to mimic a similar pattern as we do internally for versioning shared workflows. This way we don't run into the chicken & egg scenario.
Example of where we have to update tests repo to also test changes along with the other repos workflow.
https://github.com/opentdf/tests/pull/185/files#diff-e45b4e0da069e1fbfec93f1c7d808b40e8b374adaada7c22d42e434b78b652f8R35
Failing workflow: opentdf/java-sdk#154
Process should be
v1in calling reposThis process is similar to what we do internally. Follow up with @el-virt for any questions.
Acceptance Criteria:
v1