Skip to main content

moon v1.9 - VCS hooks management and improved task inheritance

· 3 min read
Miles Johnson
Miles Johnson
Founder, developer

In this release, we're introducing a long requested feature, VCS hooks! As well as a complete rewrite of our task inheritance layer.

Support for VCS hooks​

In our last release, we added support for code ownership, to better help teams manage their code review and approval workflows. To continue this trend of "features all companies require but don't have a good solution for", we're adding support for VCS hooks, starting with Git.

If you're unfamiliar with Git hooks, they're a mechanism for running scripts before or after certain Git events. For example, before a commit is added, before pushing, or after merging. Hooks can be used for such situations as:

  • Ensuring commit messages abide by a certain format.
  • Ensuring affected project's source code pass linting and formatting checks.
  • Validating configuration files.
  • And much more!
info

For more information, view our official in-depth VCS hooks guide!

New vcs settings​

To support hooks, we're introducing the vcs.hooks and vcs.syncHooks settings to .moon/workspace.yml. The former is where you configure the list of commands to run, grouped by hook type.

.moon/workspace.yml
vcs:
  hooks:
    pre-commit:
      - 'pre-commit run'
      - 'moon run :lint --affected'

The latter will automatically create and sync hooks with the local VCS checkout, enabling them going forward. Learn more about enabling hooks, and choosing the approach that works best for you or your team!

New moon sync hooks command​

Although moon can automatically create hooks when running a target, this may be undesirable or abrasive for some developers. Instead, we also support an opt-in solution through the moon sync hooks command, which will manually create the hooks.

$ moon sync hooks

Rewritten task inheritance​

One of the most complicated systems in moon is the task inheritance layer. On the surface, it sounds rather simple, but internally it was very complicated. For common use cases, it worked very well, but for advanced use cases, how a task was "inherited and merged" was sometimes undefined behavior.

Over the past year, we've introduced many new features, such as implicit dependencies and inputs, tag-based task inheritance, project-level environment variables, custom languages and platforms, and so much more. Each of these new features would throw yet another facet to be aware of during the task inheritance model, and over the past year, it has become rather unwieldy.

To rectify this situation before it becomes worse, we rewrote our project, task, and task inheritance layers from the ground-up using a new builder pattern, including writing all new unit tests, to properly and efficiently account for all edge cases.

Going forward, tasks should be far more accurate and deterministic. If you encounter any weirdness, it's either a bug/edge case that was rectified (and is no longer allowed), or a bug/edge case not accounted for in our current unit test suite. Please report them either way!

Other changes​

View the official release for a full list of changes.

  • Added --clean and --force flags to moon sync codeowners command.
  • Updated moon init to detect VCS providers and resolve fully-qualified tool versions.
  • Improved VCS file handling, caching, and performance.