Janet Goldstein authored 3 years ago and Nathan Hertz committed 3 years ago

WS-254, WS-253, WS-251: Catch ingest-complete event, parse it, and create request based on given info

old name    new name
---         ---
ready       created
executing   submitted
?           in_progress

This reverts commit 942beee0

- Local cluster can now run download workflows
- wf_monitor's timeout functionality now works the way we expect it to

- aat_wrest: utility for pulling metadata for calibration templates
- wf_framework: contains script for setting up CASA processing directory structure

removed EXPOSE cmd in frontend's Dockerfile.dev and added empty dependencies to CI stages that don't need artifacts for efficiency

- Capability request status page now grabs all correct information from its request and fills that into the UI
- If the request is complete and the execution has a delivery URL, a download button appears on the page linking to the download area

- Two new `npm` packages (not including deps): `eslint` (linter for TypeScript code) and `prettier` (multi-language web-stack code formatter)
- New workspaces component: `capability-request` which is where the work for the page is being done

WS-195, WS-76: Notification System now working and sending emails on request submission and completion

Daniel Lyons authored 4 years ago and Nathan Hertz committed 4 years ago

Added the ability to compare capability executions by their creation timestamp; made it so encountering exceptions when receiving messages does not block the system

Make the workflow_info and workflow_service singletons the same way their upper-division peers are in the capability service

Daniel Lyons authored 4 years ago and Nathan Hertz committed 4 years ago

- Datafetcher runs in container and retrieves data
- Delivery can deliver data to a directory within the container