Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define timeline / process for updating stacks in the public devfile registry - registry.devfile.io #390

Closed
1 of 3 tasks
johnmcollier opened this issue Mar 25, 2021 · 0 comments · Fixed by devfile/registry#14
Assignees
Labels
area/registry Devfile registry for stacks and infrastructure

Comments

@johnmcollier
Copy link
Member

johnmcollier commented Mar 25, 2021

With the public devfile registry, registry.devfile.io, now live and hosting devfiles from the devfile/registry repository, we need to have clearly defined process for updating the stacks in the devfile registry. The staging registry (registry.stage.devfile.io) is updated automatically with each commit to master, but the promotion to production is entirely manual and is up to us to decide when to promote.

  • Define (and document) how often scheduled updates to the public (production) registry are made
    • Discussed with @elsony earlier, and agreed once a week, on Fridays, as needed sounds like a good start.
    • Should be documented in devfile/registry's readme
  • Define (and document) how requests for emergency / interim updates to production should be made, as well as the criteria for such requests (i.e. a stack is broken)
    • Probably just open an issue in this repository with label area/registry or area/registry.devfile.io?'
    • Should be documented in devfile/registry's readme
  • Document steps for devfile services team members to perform the promotion to production
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/registry Devfile registry for stacks and infrastructure
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant