ContextQMD
Back to Moon

moon v1.8 - Code owners and shared configuration

website/blog/2023-06-12_moon-v1.8.mdx

2.2.45.1 KB
Original Source

With this release, we've focused on a critical facet of managing a large codebase, source code ownership, and sharing task configuration.

<!--truncate-->

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.

:::info

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).

yaml
codeowners:
  syncOnRun: true
  globalPaths:
    '*': ['@admins']

vcs:
  manager: 'git'
  provider: 'github'

The settings above will generate the following file:

shell
# (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.

yaml
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.

shell
# 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.

shell
$ 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:

yaml
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:

yaml
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 and MOON_RETRY_COUNT environment variables.