You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* feat: add support for explicit file arguments to validate command
Allows users to specify files directly on the command line:
bin/codeownership validate file1.rb file2.rb
This provides a more flexible alternative to the --diff flag for
validating specific files. When explicit files are provided, they
take precedence over the --diff flag and a warning is displayed.
Changes:
- Updated CLI to accept file arguments after options
- Added warning when both --diff and explicit files are provided
- Added comprehensive specs for file argument behavior
- Updated README with usage examples
* chore: bump version to 2.0.0-6
* rubocop fixes
* apply markdown formatting
* avoid stubbing stderr
* add the bundle
Copy file name to clipboardExpand all lines: README.md
+50-14Lines changed: 50 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,13 +6,14 @@ Check out [`lib/code_ownership.rb`](https://github.com/rubyatscale/code_ownershi
6
6
7
7
Check out [`code_ownership_spec.rb`](https://github.com/rubyatscale/code_ownership/blob/main/spec/lib/code_ownership_spec.rb) to see examples of how code ownership is used.
8
8
9
-
There is also a [companion VSCode Extension]([url](https://github.com/rubyatscale/code-ownership-vscode)) for this gem. Just search `Gusto.code-ownership-vscode` in the VSCode Extension Marketplace.
9
+
There is also a [companion VSCode Extension](https://github.com/rubyatscale/code-ownership-vscode) for this gem. Just search `Gusto.code-ownership-vscode` in the VSCode Extension Marketplace.
10
10
11
11
## Getting started
12
12
13
13
To get started there's a few things you should do.
14
14
15
-
1) Create a `config/code_ownership.yml` file and declare where your files live. Here's a sample to start with:
15
+
1. Create a `config/code_ownership.yml` file and declare where your files live. Here's a sample to start with:
2) Declare some teams. Here's an example, that would live at `config/teams/operations.yml`:
27
+
28
+
2. Declare some teams. Here's an example, that would live at `config/teams/operations.yml`:
29
+
27
30
```yml
28
31
name: Operations
29
32
github:
30
33
team: '@my-org/operations-team'
31
34
```
32
-
3) Declare ownership. You can do this at a directory level or at a file level. All of the files within the `owned_globs` you declared in step 1 will need to have an owner assigned (or be opted out via `unowned_globs`). See the next section for more detail.
33
-
4) Run validations when you commit, and/or in CI. If you run validations in CI, ensure that if your `.github/CODEOWNERS` file gets changed, that gets pushed to the PR.
35
+
36
+
3. Declare ownership. You can do this at a directory level or at a file level. All of the files within the `owned_globs` you declared in step 1 will need to have an owner assigned (or be opted out via `unowned_globs`). See the next section for more detail.
37
+
4. Run validations when you commit, and/or in CI. If you run validations in CI, ensure that if your `.github/CODEOWNERS` file gets changed, that gets pushed to the PR.
34
38
35
39
## Usage: Declaring Ownership
36
40
37
41
There are five ways to declare code ownership using this gem:
38
42
39
43
### Directory-Based Ownership
44
+
40
45
Directory based ownership allows for all files in that directory and all its sub-directories to be owned by one team. To define this, add a `.codeowner` file inside that directory with the name of the team as the contents of that file.
46
+
41
47
```
42
48
Team
43
49
```
44
50
45
51
### File-Annotation Based Ownership
52
+
46
53
File annotations are a last resort if there is no clear home for your code. File annotations go at the top of your file, and look like this:
54
+
47
55
```ruby
48
56
# @team MyTeam
49
57
```
50
58
51
59
### Package-Based Ownership
60
+
52
61
Package based ownership integrates [`packwerk`](https://github.com/Shopify/packwerk) and has ownership defined per package. To define that all files within a package are owned by one team, configure your `package.yml` like this:
62
+
53
63
```yml
54
64
enforce_dependency: true
55
65
enforce_privacy: true
@@ -58,16 +68,19 @@ metadata:
58
68
```
59
69
60
70
You can also define `owner` as a top-level key, e.g.
71
+
61
72
```yml
62
73
enforce_dependency: true
63
74
enforce_privacy: true
64
75
owner: Team
65
76
```
66
77
67
-
To do this, add `code_ownership` to the `require` key of your `packwerk.yml`. See https://github.com/Shopify/packwerk/blob/main/USAGE.md#loading-extensions for more information.
78
+
To do this, add `code_ownership` to the `require` key of your `packwerk.yml`. See <https://github.com/Shopify/packwerk/blob/main/USAGE.md#loading-extensions> for more information.
68
79
69
80
### Glob-Based Ownership
81
+
70
82
In your team's configured YML (see [`code_teams`](https://github.com/rubyatscale/code_teams)), you can set `owned_globs` to be a glob of files your team owns. For example, in `my_team.yml`:
83
+
71
84
```yml
72
85
name: My Team
73
86
owned_globs:
@@ -78,6 +91,7 @@ unowned_globs:
78
91
```
79
92
80
93
### Javascript Package Ownership
94
+
81
95
Javascript package based ownership allows you to specify an ownership key in a `package.json`. To use this, configure your `package.json` like this:
82
96
83
97
```json
@@ -91,6 +105,7 @@ Javascript package based ownership allows you to specify an ownership key in a `
91
105
```
92
106
93
107
You can also tell `code_ownership` where to find JS packages in the configuration, like this:
108
+
94
109
```yml
95
110
js_package_paths:
96
111
- frontend/javascripts/packages/*
@@ -101,12 +116,15 @@ This defaults `**/`, which makes it look for `package.json` files across your ap
101
116
102
117
> [!NOTE]
103
118
> Javscript package ownership does not respect `unowned_globs`. If you wish to disable usage of this feature you can set `js_package_paths` to an empty list.
119
+
104
120
```yml
105
121
js_package_paths: []
106
122
```
107
123
108
124
## Usage: Reading CodeOwnership
125
+
109
126
### `for_file`
127
+
110
128
`CodeOwnership.for_file`, given a relative path to a file returns a `CodeTeams::Team` if there is a team that owns the file, `nil` otherwise.
111
129
112
130
```ruby
@@ -118,6 +136,7 @@ Contributor note: If you are making updates to this method or the methods gettin
118
136
See `code_ownership_spec.rb` for examples.
119
137
120
138
### `for_backtrace`
139
+
121
140
`CodeOwnership.for_backtrace`can be given a backtrace and will either return `nil`, or a `CodeTeams::Team`.
122
141
123
142
```ruby
@@ -141,34 +160,38 @@ Under the hood, this finds the file where the class is defined and returns the o
141
160
See `code_ownership_spec.rb` for an example.
142
161
143
162
### `for_team`
163
+
144
164
`CodeOwnership.for_team`can be used to generate an ownership report for a team.
165
+
145
166
```ruby
146
167
CodeOwnership.for_team('My Team')
147
168
```
148
169
149
170
You can shovel this into a markdown file for easy viewing using the CLI:
A `CODEOWNERS` file defines who owns specific files or paths in a repository. When you run `bin/codeownership validate`, a `.github/CODEOWNERS` file will automatically be generated and updated.
178
+
A `CODEOWNERS` file defines who owns specific files or paths in a repository. When you run `codeownership validate`, a `.github/CODEOWNERS` file will automatically be generated and updated.
157
179
158
180
If `codeowners_path` is set in `code_ownership.yml` codeowners will use that path to generate the `CODEOWNERS` file. For example, `codeowners_path: docs` will generate `docs/CODEOWNERS`.
159
181
160
182
## Proper Configuration & Validation
161
183
162
184
CodeOwnership comes with a validation function to ensure the following things are true:
163
185
164
-
1) Only one mechanism is defining file ownership. That is -- you can't have a file annotation on a file owned via package-based or glob-based ownership. This helps make ownership behavior more clear by avoiding concerns about precedence.
165
-
2) All teams referenced as an owner for any file or package is a valid team (i.e. it's in the list of `CodeTeams.all`).
166
-
3) All files have ownership. You can specify in `unowned_globs` to represent a TODO list of files to add ownership to.
167
-
3) The `.github/CODEOWNERS` file is up to date. This is automatically corrected and staged unless specified otherwise with `bin/codeownership validate --skip-autocorrect --skip-stage`. You can turn this validation off by setting `skip_codeowners_validation: true` in `config/code_ownership.yml`.
186
+
1. Only one mechanism is defining file ownership. That is -- you can't have a file annotation on a file owned via package-based or glob-based ownership. This helps make ownership behavior more clear by avoiding concerns about precedence.
187
+
2. All teams referenced as an owner for any file or package is a valid team (i.e. it's in the list of `CodeTeams.all`).
188
+
3. All files have ownership. You can specify in `unowned_globs` to represent a TODO list of files to add ownership to.
189
+
4. The `.github/CODEOWNERS` file is up to date. This is automatically corrected and staged unless specified otherwise with `bin/codeownership validate --skip-autocorrect --skip-stage`. You can turn this validation off by setting `skip_codeowners_validation: true` in `config/code_ownership.yml`.
168
190
169
191
CodeOwnership also allows you to specify which globs and file extensions should be considered ownable.
0 commit comments