moon v1.8 - Code owners and shared configuration
With this release, we've focused on a critical facet of managing a large codebase, source code ownership, and sharing task configuration.
Support for code ownership
An important workflow for companies of any size is reviewing code, and ensuring the right people are reviewing and approving that code. This is especially true for large companies with hundreds of developers, or many distinct teams working in a single codebase.
Popular VCS providers like GitHub, GitLab, and
Bitbucket provide built-in features to handle such workflows,
aptly named code owners. They all achieve this through a similar mechanism, a single CODEOWNERS
file that maps file system paths to owners (users, teams, groups, etc). These owners are then
required to approve a pull/merge request because it can be merged into the base branch.
For more information, view our official in-depth code owners guide!
Generate a CODEOWNERS
Managing the CODEOWNERS
file manually can be a tedious task, especially when you have hundreds of
projects. To help with this, moon can generate the CODEOWNERS
file for you,
based on project owners, formatted to your VCS provider of choice.
This helps to avoid an out-of-date ownership file!
We're introducing a few new workspace settings to handle this, the first is
codeowners
, which enables and configure code ownership as a
whole, and the second is vcs.provider
, which determines the VCS
provider to generate the file for (and unlocks future features).
codeowners:
syncOnRun: true
globalPaths:
'*': ['@admins']
vcs:
manager: 'git'
provider: 'github'
The settings above will generate the following file:
# (workspace)
* @admins
While this looks very simple, it really shines once projects start adding their own granular code ownership. Continue reading for more information!
New project owners
setting
To make use of code owners, you'll need to define an owners
setting
in a project's moon.yml
file. This setting requires a list/map of owners
(contributors required to review) associated to file paths/patterns, relative from the current
project's root.
owners:
paths:
'src/': ['@frontend', '@design-system']
'*.config.js': ['@frontend-infra']
'*.json': ['@frontend-infra']
These paths will then be prefixed with the project source when
generating the CODEOWNERS
file.
# components
/packages/components/src/ @frontend @design-system
/packages/components/*.config.js @frontend-infra
/packages/components/*.json @frontend-infra
New moon sync codeowners
command
Although moon can automatically generate the CODEOWNERS
file
when running a target, there may be situations where this is disabled, or teams/developers would
like to generate the file manually. To handle this, we're providing the
moon sync codeowners
command, which will trigger the generation
process.
$ moon sync codeowners
Community-driven task configuration
A powerful but often overlooked feature of moon is the ability to share and extend task configuration from remote sources. This is extremely useful in...
- Providing a single source of truth for configuration.
- Reducing task duplication across projects.
- Ensuring tasks are battle-tested and ready for use.
The other upside of this approach is that configuration can be community-driven! To support this
as a first-class feature, we're launching the
moon-configs
repository, a collection of task
configurations for popular programming languages, frameworks, libraries, and more! As of now, the
repository is kind of empty, but we're hoping to grow it over time, so feel free to contribute!
If you're curious how this works in practice, we'll use our Rust configuration as an example. The entire system is based around tag inheritance, where a project can inherit tasks from a remote source, and then extend or override them as needed. For example, create the tag-based config:
extends: 'https://raw.githubusercontent.com/moonrepo/moon-configs/master/rust/tasks-workspace.yml'
And then in Rust projects that you'd like to inherit these tasks, add the following tags:
tags: ['rust']
It's as simple as that!
Other changes
View the official release for a full list of changes.
- Added a new action to the graph,
SyncWorkspace
, that'll be used for workspace-level checks. - Added
MOON_OUTPUT_STYLE
andMOON_RETRY_COUNT
environment variables.