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

Add Eclipse Che team as reviewers to community devfile registry content #1498

Closed
3 tasks
michael-valdron opened this issue Apr 4, 2024 · 6 comments · Fixed by devfile/registry#384
Closed
3 tasks
Assignees
Labels
area/registry Devfile registry for stacks and infrastructure kind/task

Comments

@michael-valdron
Copy link
Member

michael-valdron commented Apr 4, 2024

Which area/kind this issue is related to?

/kind task

/area registry

Issue Description

Since Eclipse Che now uses the community devfile registry directly to acquire stacks for creating workspaces, we'll need to include the Eclipse Che team as reviewers to sign off on any stack changes by us, the community, or the Che team themselves which is now included under the Eclipse Che software by default.

Acceptance Criteria

@openshift-ci openshift-ci bot added kind/task area/registry Devfile registry for stacks and infrastructure labels Apr 4, 2024
@michael-valdron
Copy link
Member Author

Best to investigate which one of these works best first and choose the one that does.

@thepetk
Copy link
Contributor

thepetk commented Apr 17, 2024

Trying to investigate the group solution and if we can have one approval per group. Will share an example from my fork soon.

@thepetk
Copy link
Contributor

thepetk commented Apr 17, 2024

I've tried to look into a possible solution that requires approval from 2 CODEOWNERS coming from two different groups of users (eclipse che & the stack owners). Sharing here my suggested approach.

  • Setup a rule of minimum 2 approvals to merge a PR.
  • Add the eclipse che group in the devfiles org and give them write access.
  • Make the eclipse che group code owners of the stacks/ directory.
  • Keep the OWNERS files in as they are so we can have explicit owners for every stack.
  • The devfile services team should be the only one merging all PRs
  • The devfile services team should make sure that every PR has the adequate number of reviews.
  • For stacks without owners the devfile services team is considered as an owner and they should be the ones approving the PRs.
  • Updates should be made to CONTRIBUTING.md in order to capture this process followed by all teams.

@michael-valdron
Copy link
Member Author

Given the decision from today's team meeting, we've decided to use the CODEOWNERS file instead of the current OWNERS files for handling reviewer teams and stack owners, this matches @thepetk's current direction for this issue: #1498 (comment)

Will update the criteria in the description to match this.

@thepetk
Copy link
Contributor

thepetk commented Apr 29, 2024

Created issue #1538 in order to add a new workflow job to check all updated stacks against dev workspaces

@thepetk
Copy link
Contributor

thepetk commented Apr 30, 2024

Opened a PR to update the CODEOWNERS & OWNERS files. Also added a process for this section inside the contributing guide.

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 kind/task
Projects
Status: Done ✅
2 participants