This describes Puppet-specific guidance for checking code into //piper/third_party/puppet.

IMPORTANT: Read go/thirdparty first.

Third-party modules

The corp platforms teams would like the opportunity to rely on third-party puppet code. However, we want to be careful when mixing code that was authored at Google and the third_party modules. Puppet modules in third_party should reside at //piper/third_party/puppet.

Adding a module

See if the module exists in //third_party/puppet/$module_name. Module names may not contain dashes ‘-’ so you will see dashes replaced with underscores. Each module should list the URL where it originated and the version (usually a GitHub commit hash.) There should be only one version of a module in use at a time.

When checked in, your module should look similar to this:


This is because the staging code that stages your module for puppet will stage the modules in the following way:


If you violate this semantic by checking code in incorrectly, your module will not function properly.

BUILD files

Modules require a BUILD file. Feel free to essentially take //piper/third_party/puppet/puppet_stdlib/BUILD as a guideline. You need to change the filegroup target and the license to match your sources, but it is a good place to start.

Changing a module

Currently, modules are globally shared across customers (mac, linux, oel, etc.). This is in contrast to our internal puppet manifests where each customer has their own repo. You should send your CLs to emailremoved@ so all customers are notified of changes. If this gets too spammy, we may make a dedicated emailremoved@ list.

ThirdParty release process

removed link to google group will control the addition and removal of packages in //piper/third_party/puppet. We may delegate OWNERs’ rights for packages as we see fit.

Module tests

Some modules come with tests. You should run them prior to committing any code. If you need help running the tests, please email emailremoved@ and someone will assist you. In the future a may run the tests for you.

Mapping modules into the puppet server namespace

It is expected that customers will use Piper fast branches (s4) to branch from //piper/third_party/puppet into //piper/.../branches in OS specific branches. It is left to customers to determine the exact details as each customer has a different release process.

Enabling third_party modules in your environment

You can edit //piper/.../environments.yaml.

Except as otherwise noted, the content of this page is licensed under CC-BY-4.0 license. Third-party product names and logos may be the trademarks of their respective owners.