Automatic pre-release catalog prep

[karlcz]

Define and add mechanisms for automatic processing in response to registry changes:

• In response to approval decisions, define new releases as latest approved content from each DCC
• In response to new release definitions, build pre-release catalog

Consider blocking/coallescing behaviors we want here. E.g.

• how often do we want releases to be defined and/or built as pre-release content if there are frequent approval decisions being entered?
• will an existing pre-release block subsequest release prep indefinitely, or will we drop and rebuild a pre-release as new content is approved?

[ACharbonneau]

Did this get resolved? Or should it get moved to the epic 2 technical debt?

[karlcz]

This is partially addressed with an admin CLI:

1. "release draft" command to idempotently create/revise a current draft release definition
2. "release build <release>" will seal the definition and construct catalog data
3. "release publsh <release>" will swap it into place as public catalog "1"
4. "release purge <release>" can destroy an abandoned pre-release
5. "release purge-auto" will clean up older content heuristically
6. "release rebuild-submissions <release>" can rebuild all constituent submissions, i.e. for platform upgrades

For now, an admin can run the commands as needed.

We could start to design some scheduled or event-driven logic to run certain behaviors automatically as part of the infrastructure:

1. Run "release draft" after submission approval state changes?
2. Run "release purge-auto" periodically (and similarlly, "submission purge-auto")?

For now, keep pre-release builds as a manual task performed ahead of scheduled release dates.

[ACharbonneau]

Do we think this is done now?

[karlcz]

Not to original statement, but maybe we don't plan to do more than current manual CLI steps? The original was about it happening automatically w/o admin involvement...