Primary repo - the one in which issues are raised
Model repo - repo for a particular model which is created from the initial issue
Actor: researcher contributing a model
Context: in primary repo
Outcome: GitHub action on primary repo:
- parses metadata
- checks metadata
- other tests such as resolving DOIs etc
- generate report on metadata status (what's missing etc)
On success: flag issue as For Review
On failure: flag issue as failed for researcher to correct, where possible add comments
Question - correcting an issue can't take the user back to the original web form, but to the markdown generated by the template
Actor: EarthByte admin
Context: primary repo
Outcome: creating model repo with README.md, file manifests and files
- manual check of issue template markdown + metadata status
- provide comments on issue for problems with metadata
On success: trigger workflow to create model repo and copy files and README.md / manifest etc
On failure: flag issue as "corrections required" for researcher to fix with comments
Actor: EarthByte admin
Context: model repo
- create model repo
- crosswalk issue metadata to primary README.md
- copies files to model repo
- adds file manifest to model repo
- populate website YAML template
On success: push to a development branch of the website to test Gatsby build?
Actor: EarthByte web admin
- build either a dev or production version of the website from the model repo
On success: notify the user via their github ID - can we post a comment on the original issue which @s the user and says "it worked and here is your URL"
On failure: if the test web build fails - notify on the model repo, not necessarily the original issue, as it may not be the result of missing metadata or other user problems
- file uploads - how do we deal with scale when there's more than a handful of files?
- create an assets directory in the model repo and provide instructions for the researcher to clone the repo, add their files and do a PR?