Giter VIP home page Giter VIP logo

pct's Introduction

title draft
Readme
false

Puppet Content Templates

Overview

Puppet Content Templates (PCT) codify a structure to produce content for any Puppet Product that can be authored by Puppet Product Teams or external users without direct help of the PDK team.

PCT can create any type of a Puppet Product project: Puppet control repo, Puppet Module, Bolt project, etc. It can create one or more independent files, such as CI files or gitignores. This can be as simple as a name for a Puppet Class, a set of CI files to add to a Puppet Module, or as complex as a complete Puppet Control repo with roles and profiles.

These are meant to be ready-to-run, which means they put everything needed for a user to run the project from the moment after creation. This solves the 'blank page' problem, where a few files are in place but the user does not know what the next steps are.

⚠️ PCT is currently in an EXPERIMENTAL phase and feedback is encouraged via pct/discussions and starting a feedback post.

Installing

While the PCT is in early release, we provide an archive and a simple script to unpack it. When we move closer to a full release we will add a platform specific installer. Use the install.[ps1|sh] script, depending upon your OS:

Unix Systems

curl -L https://pup.pt/pct/install.sh | sh

Windows Systems

iex "&{ $(irm https://pup.pt/pct/install.ps1); Install-Pct }"

This will install the latest release of PCT to ~/.puppetlabs/pct.

install_pct

⚠️ If you do not use the install script and are extracting the archive yourself, be sure to use the fully qualified path to ~/.puppetlabs/pct on *nix or $HOME/.puppetlabs/pct on Windows when you set your PATH environment variable.

A version of the product, with telemetry functionality disabled, is available too. See here for instructions on how to install it.

Setting up Tab Completion

After installation, we'd highly recommend setting up tab completion for your shell to ensure the best possible experience.

PCT has built in tab completion support for the following shells: bash, zsh, fish and powershell.

To view the install instructions, access the --help menu in pct completion and follow the instructions for your shell:

tab_completion

Quick Start Guide

This quick start guide will show you how to:

  • Create a "bare bones" Puppet module from the puppet-module-base project template
  • Add a Puppet Class to the module
  • Add a Github Actions Workflow to test the module against the currently supported Puppet versions

STEP 1: Create a Puppet Module

Let's name our module test_module using the -n flag: new_project_template

STEP 2: Add a New Class

If we cd in to the module root dir, everything will get deployed with the correct layout: new_class

STEP 3: Add a Github Actions Workflow

Want to know what configurable parameters are availble for a template and their defaults? Run pct new --info <TEMPLATE_AUTHOR>/<TEMPLATE_ID>:

new_info

We're happy with those defaults, so let's deploy this item.

Since we're outside the module root dir, we'll use the -o option to point at the root dir:

new_info

Getting Started

The $INSTALLATION_ROOT/templates directory will be subsequently referred to as the Default Template Location.

Templates currently come in 2 flavours: project and item.

  • A project is a template containing many files in a particular structure. They create a ready-to-run structure to start using a Puppet product. These are great starting points. You can create a boilerplate empty starter Puppet Module or a fully customized Puppet Module with specialized CI files and RSAPI providers.
  • An item is a template that will supplement a project or existing content. These could be language features like a Puppet class or single files like a Git ignore file.

pct new

PCT is available through the pct new command.

The --list or -l flag displays a list of locally available templates located in the Default Template Location. The list of templates is also available by calling pct new without flags.

pct new
pct new --list

Example output:

           DISPLAYNAME          |   AUTHOR   |          NAME           |  TYPE
--------------------------------+------------+-------------------------+------
                                |            |                         |
  Bolt Plan                     | puppetlabs | bolt-plan               | item
  Bolt Project                  | puppetlabs | bolt-project            | project
  Bolt PowerShell Task          | puppetlabs | bolt-pwsh-task          | item
  Bolt YAML Plan                | puppetlabs | bolt-yaml-plan          | item
  Puppet Module Managed Gemfile | puppetlabs | git-attributes          | item
  Puppet Class                  | puppetlabs | puppet-class            | item
  Puppet Content Template       | puppetlabs | puppet-content-template | project
  Puppet Defined Type           | puppetlabs | puppet-defined-type     | item
  Puppet Fact                   | puppetlabs | puppet-fact             | item
  Puppet Module                 | puppetlabs | puppet-module           | project
  Puppet Resource API Provider  | puppetlabs | rsapi-provider          | item
  Puppet Resource API Transport | puppetlabs | puppet-transport        | item

Using the available templates above, its time to generate some content.

pct new <author>/<template>

Replace <author> and <template> with the author and name of the template containing the content you want.

By default the new <author>/<template> function will use the directory name of your current working directory to "name" your new content. To override this behaviour use the --name or -n flag.

pct new <author>/<template> --name MyProject

By default the new <author>/<template> function will output the template content to the current working directory. To override this behavour use the --output or -o flag.

pct new <author>/<template> --output /path/to/your/project

📝 Not all templates require a name. If a template doesn't require one, providing a value to the --name parameter will have no effect on the generated content.

Example workflows

> cd /home/me/projects/MyBoltProject
> pct new puppetlabs/bolt-project
> pct new puppet-module -n MyNewProject -o /home/me/projects/
> cd /home/me/projects/MyNewProject
> pct new puppetlabs/puppet-fact -n ApplicationVersion
> pct new puppetlabs/rsapi-provider -n Awesomething
> pct new puppetlabs/puppet-transport -n AwesomethingApi

Template Updates

At this time pct new will NOT update existing code to a newer version of a template.

If you run a pct new command using a project template, the project will replace the content within the output directory with the template code.

If you run a pct new command using an item template, the item will suppliment the content within the output directory with the template code. If files / folders that are named the same as the template content already exist, it will overwite this content.

Writing Templates

Structure

A PCT is an archive containing a templated set of files and folders that represent a completed set of content. Files and folders stored in the template aren't limited to formal Puppet project types. Source files and folders may consist of any content that you wish to create when the template is used, even if the template engine produces just one file as its output.

Location

You can specify the location of your templates using the --templatepath option:

pct new my-name/my-custom-project --templatepath /home/me/templates

Composition

A PCT must contain a pct-config.yml in the root directory, alongside a content directory.

The content directory contains the files and folders required to produce the project or item.

To mark a file as a template, use the .tmpl extension. Templated files can also use the global variable of {{pct_name}} to access the input from the --name cli argument.

📝 Folders within the content directory can also use the {{pct_name}} variable

Example template file names:

myConfig.json.tmpl
{{pct_name}}_spec.rb

📝 One, all or none of the files can be templated.

pct-config.yml

Format of pct-config.yml

---
template:
  id: <a unique name>
  author: <name|username|orgname|handle|etc>
  type: <'item' or 'project'>
  display: <a human readable name>
  version: <semver>
  url: <url to project repo>

<template parameters>

📝 Template id and author must not contain spaces or special characters. We recommend using a hyphen to break up the identifier.

Example pct-config.yml:

---
template:
  id: example-template
  author: myorgname
  type: project
  display: Example
  version: 0.1.0
  url: https://github.com/puppetlabs/example-template

Example structure for example-template:

> tree ~/templates/example-template
/Users/me/templates/example-template
├── content
│   └── example.txt.tmpl
└── pct-config.yml

Templating Language

PCT uses Go's templating language.

Example pct-config.yml with parameters:

---
template:
  id: example-template-with-params
  author: myorgname
  type: project
  display: Example with Parameters
  version: 0.1.0
  url: https://github.com/puppetlabs/pct-example-with-params


example_params:
  foo: "bar"
  isPuppet: true
  colours:
  - "Red"
  - "Blue"
  - "Green"

In the above template example-template-with-params the parameters can be accessed in a .tmpl file like so:

{{.example_params.foo}}
{{.example_params.isPuppet}}
{{.example_params.colours}}

outputs:

bar
<no value>
[Red Blue Green]

As a template author you can chose your own parameters and parameter structure so long as it is valid YAML. Then utilise the GO templating language to display or iterate over these.

For most templates, we believe that you can do most of the things you would want with these common template controls:

// Outputs the value of `foo` defined within pct.yml
{{.example_template.foo}}

// A conditional
{{if .example_template.isPuppet}}
 "boo :("
{{else}}
 "yay!"
{{end}}

// Loops over all "colours" and renders each using {{.}}
{{range .example_template.colours}} {{.}} {{end}}

For more examples look at the existing templates provided in the Default Template Location.

Dos and Don'ts

  • project templates should provide all the code necessary to create a project from scratch and no more.
  • Do not include configuration files that can be added via an item template later by an end user, for example, CI job configuration.
  • Templates should be self documenting to help guide new users on how to use the file that has been created.

Overriding Template Defaults

Perhaps you use a template often and find that you set the same values over and over? As a template user, you can choose to override the default values specified by a template author.

📝 To view the default parameters for a template run pct new --info <TEMPLATE_ID>.

To override these defaults you need to create a pct.yml containing the template id along with the values you wish to override.

Example:

example_template:
  foo: "wibble"
  isPuppet: false
  colours:
  - "Red"
  - "Blue"

another_template:
  key: "value"

📝 You don't need to override everything

example_template:
 isPuppet: false

User level configuration

Placing a pct.yml within $HOME/.pdk/ allows you to create global overrides. Everytime you generate content from a template the configuration will be used.

Workspace configuration

You may also place a pct.yml within a workspace.

Running pct new within a directory makes the current working directory your workspace. If you specify an --outputdir that location is your workspace.

The configuration specified in a workspace pct.yml will override any configuration found within the user level configuration at $HOME/.pdk/pct.yml

Sharing Templates

After you've written your own template you may wish to share it with other members of your team or the wider Puppet community. Work is underway to improve this initial functionality.

pct build

This command will attempt to package the current working directory. You can change the directory to pack by providing --sourcedir.

pct build [--sourcedir <dir>][--targetdir <dir>]

The build command will ensure that the directory that you are attempting to package will produce a valid Puppet Content Template by looking for a pct-config.yml and a content directory.

The resulting tar.gz package will be created by default in $cwd/pkg. You can change the directory the package is created in by providing --targetdir.

Installing template packages

Packages created using the build command can be installed by extracting the tar.gz into the Default Template Location.

Local archive

Packages created using the build command can also be installed with the pct install command.

For example, this command:

pct install ~/my-template-1.2.3.tar.gz

Will install the template contained in my-template-1.2.3.tar.gz to the default template location.

Remote archive

Packages created using the build command can be automatically downloaded and extracted with pct install so long as you know the URL to where the archive is.

For example, this command:

pct install https://packages.mycompany.com/pct/my-template-1.2.3.tar.gz

Will attempt to download the PCT template from the specified url and then afterward install it like any other locally available PCT template archive.

Remote Git Repository

Git must be installed for this feature to work. The git repository must contain only one template and must be structured with the pct-config.yml file and the content directory in the root directory of the repository.

For more information on template structures see the Writing Templates section in the README.

For example, this command:

pct install --git-uri https://github.com/myorg/myawesometemplate

This will attempt to clone the PCT template from the git repository at the specified URI and install to the default template location.

Locally host documentation site

The DevX documentation site can be locally hosted and changes made to the markdown files inside of the docs/md/content directory will be visible on the site.

Prerequisites

Essential software that will need to be installed to run the documentation site locally:

  • Git version control
  • Hugo extended version
  • Nodejs and NPM

Install site

To install the documentation site run the following command from the root of this project:

./docs.sh

This will install and run the documentation site. The site can be found at http://localhost:1313. All updates will to the docs/md/content directory will hot reload the site.

To stop the running ctrl + c in the terminal window in which it is running.

Run site

Commands to run the site locally:

# Run without draft pages being displayed
./docs.sh

or

# Run with draft pages being displayed
./docs.sh -D

Requesting a feature

Open a new feature request in our Github discussion page.

Reporting Problems

If you're having trouble with the experimental PCT tool, please follow these instructions to file an issue on our GitHub repository: https://github.com/puppetlabs/pct/issues/new

Make sure to fill in the information that is requested in the issue template as it will help us investigate the problem more quickly.

Installing Telemetry Free Version

As of 0.5.0, we have been gathering telemetry data to provide insights in to how our products are being used.

The following data is collected:

  • Version of application in use
  • OS / platform of the device
  • What commands have been invoked (including command args)
  • Any errors that occurred when running the application

We understand that there will be some users who prefer to have no telemetry data sent. For those users, we offer a version of PCT with the telemetry functionality disabled.

To install:

Unix Systems

curl -L https://pup.pt/pct/install.sh | sh -s -- --no-telemetry

Windows Systems

iex "&{ $(irm https://pup.pt/pct/install.ps1); Install-Pct -NoTelemetry }"

This will install the latest release of PCT, without telemetry functionality, to ~/.puppetlabs/pct.

pct's People

Contributors

da-ar avatar michaeltlombardi avatar jpogran avatar dependabot[bot] avatar petergmurphy avatar chelnak avatar op-ct avatar david22swan avatar olatt avatar pmcmaw avatar

Stargazers

Dave Armstrong avatar  avatar John Bond avatar  avatar Toby Padilla avatar Ciaran McCrisken avatar Jacob Buchanan avatar Vlad Gusev avatar Tertius Stander avatar Sion Williams avatar Gary Bowen avatar Maarten Beeckmans avatar Derek Robinson avatar deric4 avatar  avatar Bob Henkel avatar Heston Snodgrass avatar  avatar Geoff Nichols avatar  avatar

Watchers

James Cloos avatar  avatar Cody Clements avatar Heather Preddystar-America  avatar Gillian Weisgram avatar  avatar  avatar  avatar

pct's Issues

Notify use of user config file

When using the pct tool to deploy a template, with a configured ~/.pdk/pct.yml, it would be good if the tool displayed an INFO statement telling the user the configuration was merged from the defaults provided in the template and those put in the user config file

Create install script

Create a installer script that downloads the archive, extracts to a user level location and adds that to the PATH, or instructs a user how to add to PATH.

Examples ohmyzsh or the pwsh installer script.

PCT Configuration Points

The PCT tool currently has a number of configuration points that effect how a template is rendered into a target file. You can set configuration data at the user level ~/.pdk/pct.yml and at the template level template/pct-config.yml. These two files combine with a set of standard variables pulled from the author's machine to build a set of data that templates can use.

This epic adds two new configuration points with documentation for them, and adds documentation for the existing configuration points

Display PCT Configuration to a user

As a Content User I would like to see what configuration options for a given template. This would be useful before deploying a template and after.

For example with a puppet-module template that provides the following configuration options:

---
template:
  id: puppet-module
  type: project
  display: Puppet Module
  version: 0.1.0
  url: https://github.com/puppetlabs/pct-puppet-module

puppet_module:
  license: "Apache-2.0"
  version: "0.1.0"
  summary: "A New Puppet Module"
  operatingsystem_support:
    - operatingsystem: "windows"
      release: [2019, 10]

It should display on the command line:

> pct new -l puppet-module
DisplayName:     Puppet Module
Name:            puppet-module
TemplateType:    project
TemplateURL:     https://github.com/puppetlabs/pct-puppet-module
TemplateVersion: 0.1.0

Data:
  puppet_module:
    license: "Apache-2.0"
    version: "0.1.0"
    summary: "A New Puppet Module"
    operatingsystem_support:
      - operatingsystem: "windows"
        release: [2019, 10]

It should also include the default built-in data points like version information, user, etc.

PDK Shell wrapper

The PDK golang port will need the ability to invoke the current PDK Ruby commandline for any features that have not yet been ported.

This wrapper should:

  • Replace the existing nix and Windows shell wrappers
  • Handle setting up the environment variables for PDK to execute Ruby
  • Handle constructing the correct command line to invoke the PDK Ruby binary
  • Should return output to the console in the same way PDK Ruby does

It is important that this wrapper return information to the console in the same way the existing PDK Ruby does so as to not break any current scripts.

Implementing all of the existing PDK command and subcommand cobra command handlers is a separate ticket. This ticket should pick one to implement to test the technical implementation, but leave the rest as separate work.

Implement install from a local tar.gz file

This ticket implements the methods to take an existing tar file, extract it, and deploy the it to the template cache path.

This is implemented inside the existing pct package

  • Read from TAR file and deploy to $TEMPLATE_ROOT_DIR
  • If template already exists, delete and overwrite

Determine list of starter Puppet Content Templates

Evaluate existing set of PCT experimentations to see if any are worthy first example templates.
Evaluate whether any new template should be created.
End goal is a short list of example templates that showcase using PCT
Do not create templates for this ticket

Puppet Content Template Inheritance

A a content template author I want to author templates that can be reused in multiple PCTs, so that I reduce duplication of common language features and reduce drift between deployed versions.

As a content template user I want to be able to reference a PCT that has reusable templates inside a PCT I create, so I can control deployment of language features and files without having to write templates myself.

Create starter Puppet Content Templates

Using results from #18 ticket, create a set of PCTs that exemplify the new template system.
Should be at least one project and one item template to show creating a project and adding content to it.

Unit testing improvements

Investigate how golang interfaces might help unit testing the code. Currently the unit tests cover the PCT package from API surface down, but there are minimal to no unit testing from the cobra command level down. This misses input validation and other user error cases.

Base Template API

Use existing code so that we have a releasable artifact
Clean up enough that it can be modified in the future based on feedback
Name the binary pct so that it is not related to existing PDK

Install a Puppet Content Template

As a content template user I want to install PCTs using the command line. I should be able to install a PCT with a similar experience like a Puppet Module install so I don't have to learn a new paradigm.

Error if template id not found

Currently is a user enters in a incorrect template id the tool does not present an error but does nothing.

The tool should report the template is not found with a readable error message indicating that the name is incorrect or the template is not present

Tab completion concatenating template name to end of ID on zsh

Environment

OS: macOS 11.3.1
Terminal: Native macOS Terminal App (2.11 (440))
Shell: zsh 5.7.1 (x86_64-apple-darwin18.2.0)

Issue Details

When tabbing out for completion of a template name, if there is only one option available, the tab completion appends the template's name (i.e. human readable name) to the end, on top on the id.

autocomplete_templ_name_included.gif

Steps to Reproduce

  • Build the pct experimental binary
  • Run pct new puppet-c [TAB]

Notes

  • This does not occur if there are multiple template IDs available for tab completion (e.g. pct new p [TAB])

Review item template deploy location

The pct tool should produce a file or a set of files in the expected location based on PCT type

For project template types:

If name and output are not given, it should use the current working directory for output and it should use the name of the folder in output for name.

# cwd is C:\Users\james\src\test1
❯ pct new puppet-module
7:33PM INF Deployed: C:\Users\james\src\test1
7:33PM INF Deployed: C:\Users\james\src\test1\.fixtures.yml
7:33PM INF Deployed: C:\Users\james\src\test1\CHANGELOG.md
7:33PM INF Deployed: C:\Users\james\src\test1\README.md
7:33PM INF Deployed: C:\Users\james\src\test1\data
7:33PM INF Deployed: C:\Users\james\src\test1\data\common.yaml
7:33PM INF Deployed: C:\Users\james\src\test1\examples
7:33PM INF Deployed: C:\Users\james\src\test1\files
7:33PM INF Deployed: C:\Users\james\src\test1\hiera.yaml
7:33PM INF Deployed: C:\Users\james\src\test1\manifests
7:33PM INF Deployed: C:\Users\james\src\test1\metadata.json
7:33PM INF Deployed: C:\Users\james\src\test1\templates

If name is given and output is not given, it should use the value for name and set output to the current working directory plus the name.

# cwd is C:\Users\james\src
❯ pct new puppet-module --name test1
7:32PM INF Deployed: C:\Users\james\src\test1
7:32PM INF Deployed: C:\Users\james\src\test1\.fixtures.yml
7:32PM INF Deployed: C:\Users\james\src\test1\CHANGELOG.md
7:32PM INF Deployed: C:\Users\james\src\test1\README.md
7:32PM INF Deployed: C:\Users\james\src\test1\data
7:32PM INF Deployed: C:\Users\james\src\test1\data\common.yaml
7:32PM INF Deployed: C:\Users\james\src\test1\examples
7:32PM INF Deployed: C:\Users\james\src\test1\files
7:32PM INF Deployed: C:\Users\james\src\test1\hiera.yaml
7:32PM INF Deployed: C:\Users\james\src\test1\manifests
7:32PM INF Deployed: C:\Users\james\src\test1\metadata.json
7:32PM INF Deployed: C:\Users\james\src\test1\templates

If name is not given and output is given, it should use the name of the folder in output for name.

# cwd is C:\Users\james\src
❯ pct new puppet-module --output C:\Users\james\src\test1
7:32PM INF Deployed: C:\Users\james\src\test1
7:32PM INF Deployed: C:\Users\james\src\test1\.fixtures.yml
7:32PM INF Deployed: C:\Users\james\src\test1\CHANGELOG.md
7:32PM INF Deployed: C:\Users\james\src\test1\README.md
7:32PM INF Deployed: C:\Users\james\src\test1\data
7:32PM INF Deployed: C:\Users\james\src\test1\data\common.yaml
7:32PM INF Deployed: C:\Users\james\src\test1\examples
7:32PM INF Deployed: C:\Users\james\src\test1\files
7:32PM INF Deployed: C:\Users\james\src\test1\hiera.yaml
7:32PM INF Deployed: C:\Users\james\src\test1\manifests
7:32PM INF Deployed: C:\Users\james\src\test1\metadata.json
7:32PM INF Deployed: C:\Users\james\src\test1\templates

If name and output are given, then it should use those values. It should also check to see if output has name in it. If output does not have name in it, then it should add name to output.

# cwd is C:\Users\james (or anywhere)
❯ pct new puppet-module --name test1 --output C:\Users\james\src
7:43PM INF Deployed: C:\Users\james\src\test1
7:43PM INF Deployed: C:\Users\james\src\test1\.fixtures.yml
7:43PM INF Deployed: C:\Users\james\src\test1\CHANGELOG.md
7:43PM INF Deployed: C:\Users\james\src\test1\README.md
7:43PM INF Deployed: C:\Users\james\src\test1\data
7:43PM INF Deployed: C:\Users\james\src\test1\data\common.yaml
7:43PM INF Deployed: C:\Users\james\src\test1\examples
7:43PM INF Deployed: C:\Users\james\src\test1\files
7:43PM INF Deployed: C:\Users\james\src\test1\hiera.yaml
7:43PM INF Deployed: C:\Users\james\src\test1\manifests
7:43PM INF Deployed: C:\Users\james\src\test1\metadata.json
7:43PM INF Deployed: C:\Users\james\src\test1\templates

For item template types:

If name and output are not given, it should use the current working directory for output and it should use the name of the folder in output for name.

# fail
# cwd is C:\Users\james\src\foo
❯ pct new puppet-class
7:48PM INF Deployed: C:\Users\james\src
7:48PM INF Deployed: C:\Users\james\src\manifests
7:48PM INF Deployed: C:\Users\james\src\manifests\foo.rb
7:48PM INF Deployed: C:\Users\james\src\spec
7:48PM INF Deployed: C:\Users\james\src\spec\classes
7:48PM INF Deployed: C:\Users\james\src\spec\classes\foo_spec.rb

If name is given and output is not given, it should use the value for name and set output to the current working directory. *It does not append name to output

# cwd is C:\Users\james\src\foo
❯ pct new puppet-class --name test1
7:50PM INF Deployed: C:\Users\james\src\foo
7:50PM INF Deployed: C:\Users\james\src\foo\manifests
7:50PM INF Deployed: C:\Users\james\src\foo\manifests\test1.rb
7:50PM INF Deployed: C:\Users\james\src\foo\spec
7:50PM INF Deployed: C:\Users\james\src\foo\spec\classes
7:50PM INF Deployed: C:\Users\james\src\foo\spec\classes\test1_spec.rb

If name is not given and output is given, it should use the name of the folder in output for name. *It does not append name to output. *It does not remove name from output.

# fail
# cwd is C:\Users\james\src
❯ pct new puppet-class --output C:\Users\james\src\test1
7:52PM INF Deployed: C:\Users\james\src\test1
7:52PM INF Deployed: C:\Users\james\src\test1\manifests
7:52PM INF Deployed: C:\Users\james\src\test1\manifests\foo.rb
7:52PM INF Deployed: C:\Users\james\src\test1\spec
7:52PM INF Deployed: C:\Users\james\src\test1\spec\classes
7:52PM INF Deployed: C:\Users\james\src\test1\spec\classes\foo_spec.rb

If name and output are given, then it should use those values. It should not change output or name based on any rule.

❯ pct new puppet-class --name test1 --output C:\Users\james\src\foo
7:56PM INF Deployed: C:\Users\james\src\foo
7:56PM INF Deployed: C:\Users\james\src\foo\manifests
7:56PM INF Deployed: C:\Users\james\src\foo\manifests\test1.rb
7:56PM INF Deployed: C:\Users\james\src\foo\spec
7:56PM INF Deployed: C:\Users\james\src\foo\spec\classes
7:56PM INF Deployed: C:\Users\james\src\foo\spec\classes\test1_spec.rb

Environment variable based configuration

As a content user i would like to set an environment variable that adds configuration data to a template instead of a config file.

This may not be implemented based on the results from #83

Domain specific Input

Should the tool understand enough about the domain the template works in to 'know' how certain conventions act.

Example, creating a puppet class inside a puppet module needs to be named modulename::classname. If the user does not supply this should the tool do this.

Workspace based configuration

As a content user I would like to create a config file that would be read by PCT to set certain variables inside a template when rendered. This is separate from a user config file, as it has details that is only relevant for the current workspace.

Example is the puppet module name when creating a puppet class. Currently creating a class requires a module name, but there isn't a way to find out the module name when rendering the template. If a config file was placed inside the module folder with the 'module name' in it, then it could be read when

It looks for a config in it's current working directory. If it finds it, this will override any existing config. This way if someone saves a config file inside a project/folder/thing, it will override anything else. Modelled after VS Code workspace settings.

This will fit into the existing configuration hierarchy after user config.

/*
Inheritance (each level overwritten by next):
  convention based variables
    - pdk specific variables based on transformed user input
  machine variables
    - information that comes from the current machine
    - user name, hostname, etc
  template variables
    - information from the template itself ./pct-config.yml
    - designed to be runnable defaults for everything inside template
  user overrides
    - ~/.pdk/pdk.yml
    - user customizations for their preferences
  outputdir or current working directory
    - target specific information
    - if no file in outputdir, fallback current working directory
    - e.g a puppet module name for a puppet class
    - e.g. control repo has default values for certain parts of it
    - think vscode workspace settings
*/

Unify build scripts

The local build scripts and the goreleaser script do different things and as the project continues to grow the differences will become more confusing.

Investigate Acceptance testing

This ticket should investigate and create a simple small acceptance testing framework for the project. Current tests are unit tests and can't fully exercise the command line input. We need a way to execute from the command line the binary and test that the output matches expectations.

  • rake rspec
  • pwsh Pester
  • simple shell script with a list of examples

Determine storage place for starter Puppet Content Templates

Evaluate storing templates in one github repo or multiple, take into consideration adding this to the automatic pdkgo release process

This ticket purely handles where we are storing in VCS the initial set of example templates. Decide if we store in one repo per template or one repo as a starter pack. This will create tickets on either architectural detail and/or repo creation.

  • If we store as one repo per template, we need to figure out repo naming, template naming and local folder naming.
  • If we store as a temporary 'starter' repo, we can archive as we discover final implementation.

Ensure pdkshell can handle scenarios where RVM rubies are prioritised on $PATH

Describe the Bug

When using RVM, the pdkshell#Execute method fails to exec the natively installed Ruby based PDK:

/home/user/pdkgo/pdk validate
/opt/puppetlabs/pdk/private/ruby/2.4.10/lib/ruby/site_ruby/2.4.0/rubygems.rb:277:in `find_spec_for_exe': can't find gem pdk (>= 0.a) with executable pdk (Gem::GemNotFoundException)
	from /opt/puppetlabs/pdk/private/ruby/2.4.10/lib/ruby/site_ruby/2.4.0/rubygems.rb:296:in `activate_bin_path'
	from /opt/puppetlabs/pdk/private/ruby/2.4.10/bin/pdk:23:in `<main>'
12:01PM FTL ../pdkgo/internal/pkg/pdkshell/pdkshell.go:41 > pdk failed with 'exit status 1'

Expected Behaviour

When attempting to execute any of the PDK Shell wrapper commands (pdk validate, pdk test unit, etc...), with RVM installed on a system, the wrapper commands successfully execute.

Steps to Reproduce

Steps to reproduce the behaviour:

  1. Obtain an Ubuntu 20.04 host (e.g. using floaty: floaty get ubuntu-2004-x86_64)
  2. Set up a non root user, with sudo perms:
adduser user
usermod -aG sudo user
su user
cd
  1. Install RVM:
sudo apt install gnupg2
gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
\curl -sSL https://get.rvm.io | bash -s stable
source /home/user/.rvm/scripts/rvm
  1. Install Ruby 2.7:
rvm install "ruby-2.7.2"
rvm use 2.7
  1. Install the PDK:
wget https://apt.puppet.com/puppet-tools-release-focal.deb
sudo dpkg -i puppet-tools-release-focal.deb
sudo apt update
sudo apt install pdk
  1. Install go:
wget -c https://golang.org/dl/go1.16.3.linux-amd64.tar.gz -O - | sudo tar -xz -C /usr/local
export PATH=$PATH:/usr/local/go/bin
  1. Clone the pdkgo project:
sudo apt install git
git clone https://github.com/puppetlabs/pdkgo
  1. Build:
cd pdkgo
./build.sh
  1. Clone a module:
cd ..
git clone https://github.com/puppetlabs/puppetlabs-motd
cd puppetlabs-motd
  1. Attempt to run a shell wrapper command:
/home/user/pdkgo/pdk validate

Create installation scripts for PCT LA

Create installation scripts that can be fetched and invoked in the shell like this:

sh -c "$(curl https://pup.pt/install-pct.sh)"

This should install the latest version of the PCT release to $HOME/.puppetlabs/pct

Template inheritance

Feedback from early users indicate a desire to have a template inheritance workflow. Create a base template that one or more partials that have reusable bits of template in them. Then have templates that can reference them without having to copy their template code.

This introduces deployment, dependency, and code complexity. This ticket should produce a spec on a potential solution so that we can decide from an architectural standpoint whether we support this workflow or not

Example:

Base

# puppet-base/layouts/puppet/class.tmpl
{{ define "puppet_class" }}
class {{.class_name}} (){
}
{{ end }}

Downlevel:

# content/lib/manifest/{{pct_name}}.rb.tmpl
{{ template "puppet_class" .}}

Tested golang wrapper

The golang wrapper over the Ruby commands works and is tested manually with a few of the commands.

To accomplish the goal of having it replace the bash and pwsh wrapper scripts, we need a documented set of trials to test it working in real world scenarios

Set of Starter Templates

Decide on the minimum set of starter Puppet Content Templates to build out for the first round of feedback.

The list of templates should include at least one project and one item template, but could include a whole set of templates that perform one 'thing'.

For example, a Puppet Module template that create a starter module with an example RSAPI provider, or a Github CI config for a module project.

Template authoring tips

Add to initial doc a set of authoring tips:

  • use pct new puppet-content-template to get started
  • install go-template vscode extension for syntax highlighting

Tested golang wrapper

The golang wrapper over the Ruby commands works and is tested manually with a few of the commands.

To accomplish the goal of having it replace the bash and pwsh wrapper scripts, we need a documented set of trials to test it working in real world scenarios

IAC Blog Post announcing PCT LA release

We should write a blog post for the IAC Blog announcing the availability of the PCT LA release.

What would also be nice to include is:

  • Details on how to provide feedback (via a Github Discussion or something similar)
  • Where to raise questions (Slack, Github, etc...)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.