|
| 1 | +# Configuration |
| 2 | + |
| 3 | +To get started there's a few things you should do. |
| 4 | + |
| 5 | +1) Create a `config/code_ownership.yml` file and declare where your files live. Here's a sample to start with: |
| 6 | + |
| 7 | +```yml |
| 8 | +owned_globs: |
| 9 | + - '{app,components,config,frontend,lib,packs,spec}/**/*.{rb,rake,js,jsx,ts,tsx}' |
| 10 | +js_package_paths: [] |
| 11 | +unowned_globs: |
| 12 | + - db/**/* |
| 13 | + - app/services/some_file1.rb |
| 14 | + - app/services/some_file2.rb |
| 15 | + - frontend/javascripts/**/__generated__/**/* |
| 16 | +``` |
| 17 | +
|
| 18 | +2) Declare some teams. Here's an example, that would live at `config/teams/operations.yml`: |
| 19 | + |
| 20 | +```yml |
| 21 | +name: Operations |
| 22 | +github: |
| 23 | + team: '@my-org/operations-team' |
| 24 | +``` |
| 25 | + |
| 26 | +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. |
| 27 | +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. |
| 28 | + |
| 29 | +## Usage: Declaring Ownership |
| 30 | + |
| 31 | +There are three ways to declare code ownership using this gem. |
| 32 | + |
| 33 | +### Directory-Based Ownership |
| 34 | + |
| 35 | +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. |
| 36 | + |
| 37 | +```text |
| 38 | +Team |
| 39 | +``` |
| 40 | + |
| 41 | +### File-Annotation Based Ownership |
| 42 | + |
| 43 | +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: |
| 44 | + |
| 45 | +```ruby |
| 46 | +# @team MyTeam |
| 47 | +``` |
| 48 | + |
| 49 | +### Package-Based Ownership |
| 50 | + |
| 51 | +Package based ownership integrates [`pks`](https://github.com/rubyatscale/pks) 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: |
| 52 | + |
| 53 | +```yml |
| 54 | +enforce_dependency: true |
| 55 | +enforce_privacy: true |
| 56 | +metadata: |
| 57 | + owner: Team |
| 58 | +``` |
| 59 | + |
| 60 | +You can also define `owner` as a top-level key, e.g. |
| 61 | + |
| 62 | +```yml |
| 63 | +enforce_dependency: true |
| 64 | +enforce_privacy: true |
| 65 | +owner: Team |
| 66 | +``` |
| 67 | + |
| 68 | +### Glob-Based Ownership |
| 69 | + |
| 70 | +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`: |
| 71 | + |
| 72 | +```yml |
| 73 | +name: My Team |
| 74 | +owned_globs: |
| 75 | + - app/services/stuff_belonging_to_my_team/**/** |
| 76 | + - app/controllers/other_stuff_belonging_to_my_team/**/** |
| 77 | +``` |
| 78 | + |
| 79 | +### Javascript Package Ownership |
| 80 | + |
| 81 | +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 | + |
| 83 | +```json |
| 84 | +{ |
| 85 | + // other keys |
| 86 | + "metadata": { |
| 87 | + "owner": "My Team" |
| 88 | + } |
| 89 | + // other keys |
| 90 | +} |
| 91 | +``` |
| 92 | + |
| 93 | +You can also tell `codeowners` where to find JS packages in the configuration, like this: |
| 94 | + |
| 95 | +```yml |
| 96 | +js_package_paths: |
| 97 | + - frontend/javascripts/packages/* |
| 98 | + - frontend/other_location_for_packages/* |
| 99 | +``` |
| 100 | + |
| 101 | +This defaults `**/`, which makes it look for `package.json` files across your application. |
| 102 | + |
| 103 | +> [!NOTE] |
| 104 | +> 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. |
| 105 | + |
| 106 | +```yml |
| 107 | +js_package_paths: [] |
| 108 | +``` |
| 109 | + |
| 110 | +## Usage: Generating a `CODEOWNERS` file |
| 111 | + |
| 112 | +A `CODEOWNERS` file defines who owns specific files or paths in a repository. When you run `codeowners generate-and-validate`, a `.github/CODEOWNERS` file will automatically be generated and updated. |
| 113 | + |
| 114 | +## Proper Configuration & Validation |
| 115 | + |
| 116 | +CodeOwnership comes with a validation function to ensure the following things are true: |
| 117 | + |
| 118 | +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. |
| 119 | +2) All teams referenced as an owner for any file or package is a valid team. |
| 120 | +3) All files have ownership. You can specify in `unowned_globs` to represent a TODO list of files to add ownership to. |
| 121 | +4) The `.github/CODEOWNERS` file is up to date. This is automatically corrected and staged unless specified otherwise with `codeowners generate-and-validate`. |
| 122 | + |
| 123 | +CodeOwnership also allows you to specify which globs and file extensions should be considered ownable. |
| 124 | + |
| 125 | +Here is an example `config/code_ownership.yml`. |
| 126 | + |
| 127 | +```yml |
| 128 | +owned_globs: |
| 129 | + - '{app,components,config,frontend,lib,packs,spec}/**/*.{rb,rake,js,jsx,ts,tsx}' |
| 130 | +unowned_globs: |
| 131 | + - db/**/* |
| 132 | + - app/services/some_file1.rb |
| 133 | + - app/services/some_file2.rb |
| 134 | + - frontend/javascripts/**/__generated__/**/* |
| 135 | +``` |
0 commit comments