RC-v1.2.0

[patmagee]

Motivation

This release focuses on two main themes: Observability and Scalability.

Observability: As more people have adopted WES it has become clear that the current API does not provide enough information for end users. The RunStatus and Log models have limited required keys and making actionable decisions on the information that is available is difficult without performing additional requests.

Scalability: As more implementors are looking to "productize" WES, the topic of scalability has continuously come up. Specific features of WES (such as embedded task logs) make implementing WES API a challenge, and can cause the service to break (Ie too many task cause a service to consume too much memory).

What's Changed

• feat: added run state PREEMPTED by @vsmalladi in feat: add run state PREEMPTED #188
• feat: add in support for workflow engine and version when submitting a request by @vsmalladi in feat: add in support for workflow engine and version when submitting a request. Closes #181 #182
• feat: add alternative schema for array items in RunListResponse by @uniqueg in feat: add alternative schema for array items in RunListResponse #207
  • DEPRECATION NOTICE: the RunListResponse model will only return RunSummary starting in 2.0.0
• feat: created a new endpoint to paginate run tasks by @patmagee in Added new endpoint to paginate a Workflow Run task_logs #177
  • DEPRECATION NOTICE: the task_logs property in the RunLog model has been deprecated in favour of the task list endpoint, and will be removed in 2.0.0
• feat: make Tasks Addressable by ID and extend available information in the task log by @patmagee in Feat: Make Tasks Addressable by ID and extend available information #205

Additional Improvements

• Removed travis CI integration and added GitHub actions for publishing docs and linting openapi.yaml
• Removed example python client code in b5f782e
• Removed duplicated swagger specification in favour of consolidated OpenAPI3 specification

[uniqueg]

Thanks a lot for this @patmagee!

I would just like to point out that there is neither a tag nor a release for 1.1.0 yet. So I guess we should either find the commit that was supposed to represent 1.1.0, tag that and create a release (as discussed here for 1.0.1: #191) or set the upcoming release associated with this PR to 1.1.0.

Of note: The workflow version indicated in branch develop is still, as of today (last update 2 hours ago), 1.0.1. See

workflow-execution-service-schemas/openapi/workflow_execution_service.openapi.yaml

Line 5 in ec84aa4

version: '1.0.1'

.

As @vinjana pointed out here, the 1.0.1 release didn't follow SemVer (should have been 1.1.0 instead), but that is now history. But I think one thing we could do is bump the current version in develop to 1.1.0, tag and release. Then rebase this PR against that for a 1.2.0 release.

[vsmalladi]

@uniqueg and @patmagee I think the intention was 1.0.1 was supposed to be 1.1.0. Thus my recommendation would be to add another taged release at the same commit as 1.0.1 and mention in the notes that this was supposed to be SemVer 1.1.0, but don't change the version in the repo. In tag release notes 1.2.0 explain the issue and why we moved to SemVer 1.2.0