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.

Sign up for GitHub

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 CODEOWNERS #220

Merged
merged 2 commits into from
Sep 8, 2023
Merged

Add CODEOWNERS #220

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bdee977
Add CODEOWNERS
withinfocus Sep 7, 2023
017120b
Merge branch 'master' into owners
withinfocus Sep 8, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions .github/CODEOWNERS
View file
Open in desktop
Validating CODEOWNERS rules …
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
# Please sort into logical groups with comment headers. Sort groups in order of specificity.
# For example, default owners should always be the first group.
# Sort lines alphabetically within these groups to avoid accidentally adding duplicates.
#
# https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners


# DevOps for Actions and other workflow changes.
.github/workflows @bitwarden/dept-devops
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only the release pipelines are really owned by devops.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this with DevOps and they'd like general oversight of workflows altogether. This is a good best practice as they possess a lot of knowledge about GitHub workflows. Additionally, we have seen a lot of benefits come from collaboration -- the test repo being a good example.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fine and we typically do request review from devops when it makes sense. However I don't want to block PRs requiring minor changes to the workflows before we can ensure the process works. (Check contributing docs)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in place for our biggest repos today. DevOps is available to review changes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However I don't want to block PRs requiring minor changes to the workflows before we can ensure the process works.

Is this referring to the Code Owner review process? or the process that is being written and updated in the GitHub Workflow itself?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joseph-flinn The review process. The workflows in this repo aren't stable (other than the publish) and we tend to make minor adjustments frequently. I mainly don't want to go ping devops all the time but if that's our process I'll do it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, thanks!

Long term, I'd like to see DevOps set up more robust tooling around workflow changes (mostly linting) to enable a better development experience for all engineering teams while working in the pipelines while also enforcing secure industry practices. I'll work with the team to have quick turn around times for workflow changes until we have capacity to build out the tooling.