The goal is to have several repos, each representing a server, which can be taken over by a community that governs the contents of that server. Generic components apply to all servers and should not live in every repo.
Right now this repo really has a several things:
- asset_pep/ -- a PEP describing the assets for this server
- pipeline_interfaces/ -- looper interfaces for downloading, building, and archiving . This is the connection between the PEP and refgenie.
- config/... -- the config file representation of that PEP (output of refgenie runs)
- task_defs/ -- the AWS image descriptions for autodeploy
- .github/ -- github actions defined for automatic deploy
Some of these are specific to this server instance, others are generic.
specific: asset_pep, config.
generic: pipeline_interfaces, task_defs, .github
We could:
- factor out taskdefs and .github into a generic github action that could be called from multiple repos.
- move pipeline interfaces into a separate repo that provides everything needed for the download/build/archive steps.
The goal is to have several repos, each representing a server, which can be taken over by a community that governs the contents of that server. Generic components apply to all servers and should not live in every repo.
Right now this repo really has a several things:
Some of these are specific to this server instance, others are generic.
specific: asset_pep, config.
generic: pipeline_interfaces, task_defs, .github
We could: