In order to have a stable catalog-next to test against, data.gov admins wants a protected branch and infrastructure for another catalog to be deployed.
Acceptance Criteria
[ACs should be clearly demoable/verifiable whenever possible. Try specifying them using BDD.]
[ ] GIVEN the next branch is created and protected \
[AND optionally another precondition] \
WHEN a user goes to catalog-next \
THEN the CKAN site is up \
AND the harvest extension (and others) are not installed.
We want to utilize current models where we can. Suggest implement a next branch, and a similar branch for ckanext-datagovteam such that the next branch in catalog is protected, requires reviews for merge, etc. We also want to deploy on next branch merges, and figure out how to separate that from main.
In this iteration we only need to do development for dev; stage and prod can be considered follow-up tickets (please create follow up tickets if not implemented).
User Story
In order to have a stable catalog-next to test against, data.gov admins wants a protected branch and infrastructure for another catalog to be deployed.
Acceptance Criteria
[ACs should be clearly demoable/verifiable whenever possible. Try specifying them using BDD.]
nextbranch is created and protected \ [AND optionally another precondition] \ WHEN a user goes to catalog-next \ THEN the CKAN site is up \ AND the harvest extension (and others) are not installed.Background
Related to Harvesting2.0
Security Considerations (required)
None
Sketch
We want to utilize current models where we can. Suggest implement a
nextbranch, and a similar branch forckanext-datagovteamsuch that thenextbranch in catalog is protected, requires reviews for merge, etc. We also want to deploy onnextbranch merges, and figure out how to separate that frommain. In this iteration we only need to do development for dev; stage and prod can be considered follow-up tickets (please create follow up tickets if not implemented).