Skip to content

Latest commit

 

History

History
722 lines (552 loc) · 36.7 KB

README.adoc

File metadata and controls

722 lines (552 loc) · 36.7 KB
Raw

Milestoner

Milestoner is a pure Git based Command Line Interface (CLI) for software deployment automation that is agnostic of the programming language or source control service you use (i.e. GitHub, GitLab, Bitbucket, etc). Each milestone (i.e. Git tag) includes the automatic generation of feature rich release notes sourced from the Git commits that make up the tag. Finally, each milestone adheres to Strict Semantic Versioning so your milestones remain consistent.

You can use Milestoner to inspect the current state of the next milestone, celebrate the team members that contribute to each milestone, and share information with stakeholders with minimal effort. By having a tool, like Milestoner, you can automate software releases in a consistent and reliable fashion. 🎉

Milestoner pairs well with the following gems:

  • Git Lint: Lints each Git commit to ensure they are of high quality for readability, historic inspection, and release note generation.

  • Rubysmith: Automates building new Ruby projects.

  • Gemsmith: Automates building new RubyGems projects.

  • Hanamismith: Automates building new Hanami projects.

Table of Contents

Screenshots

The following are screenshots of using this gem to render release notes for the Lode gem. Even though Lode is used for example purposes, keep in mind that Milestoner can be used for any project and/or programming language.

ASCII Doc

Release Notes

Release Notes

  • Command: milestoner build --format ascii_doc

  • Renderer: ASCII Doc

Feed

Release Notes

Release Notes

  • Command: milestoner build --format feed

  • Renderer: NetNewsWire

Markdown Format

Release Notes

  • Command: milestoner build --format markdown

  • Renderer: Marked 2

Stream

Release Notes

  • Command: milestoner build --format stream

  • Renderer: iTerm 2

Web

Release Notes

Release Notes

  • Command: milestoner build --format web

  • Renderer: Firefox

Features

  • Uses Versionaire for Strict Semantic Versioning. Example:

    • Format: <major>.<minor>.<patch>.

    • Example: 0.0.0.

  • Defaults to including Git commits since last tag (or initialization of repository) when building release notes. This can be customized further if desired.

  • Ensures Git commit messages are grouped by prefix, in order defined, for categorization. For more details, see Git Lint Commit Subject Prefix. Defaults (can be customized):

    • Fixed Fixed

    • Added Added

    • Updated Updated

    • Removed Removed

    • Refactored Refactored

  • Ensures Git commit messages are alphabetically sorted for release note categorization and readability.

  • Provides automatic versioning based on last Git tag and Git Trailers. See Git Commit Anatomy for details.

  • Supports multiple build formats:

  • Supports Git Notes.

  • Supports customization via your personal XDG, Runcom, and/or Hanami Views configuration.

Requirements

  1. A UNIX-based system.

  2. Ruby.

  3. GnuPG (optional).

Setup

To install with security, run:

# 💡 Skip this line if you already have the public certificate installed.
gem cert --add <(curl --compressed --location https://alchemists.io/gems.pem)
gem install milestoner --trust-policy HighSecurity

To install without security, run:

gem install milestoner

Usage

Command Line Interface (CLI)

From the command line, type: milestoner --help

Usage

Customization

This gem can be configured via a global configuration:

~/.config/milestoner/configuration.yml

It can also be configured via XDG environment variables.

The default configuration is:

avatar:
  uri: "https://avatars.githubusercontent.com/u/%<id>s"
build:
  basename: "index"
  format: "stream"
  layout: "page"
  max: 1
  root: "tmp/milestones"
  stylesheet: "page"
  tail: "head"
commit:
  categories:
    - emoji: "✅"
      label: "Fixed"
    - emoji: "🟢"
      label: "Added"
    - emoji: "🔼"
      label: "Updated"
    - emoji: "⛔️"
      label: "Removed"
    - emoji: "🔁"
      label: "Refactored"
  format: "asciidoc"
  uri: "https://github.com/%<project_owner>s/%<project_name>s/commit/%<id>s"
organization:
  label: "Undefined"
  uri: "https://undefined.io"
profile:
  uri: "https://github.com/%<id>s"
project:
  owner: "undefined"
  uri:
    home: "%<organization_uri>s/projects/%<project_name>s"
    version: "%<project_uri_home>s/versions/%<id>s"
review:
  uri: "https://github.com/%<project_owner>s/%<project_name>s/pulls/%<id>s"
syndication:
  categories:
    - label: "Milestones"
      name: "milestones"
  entry:
    label: "%<id>s"
    uri: "%<project_uri_version>s"
  id: "%<project_uri_version>s"
  label: "%<organization_label>s: %<project_label>s"
  links:
    - label: "%<organization_label>s: %<project_label>s (web)"
      mime: "text/html"
      relation: "alternate"
      uri: "%<project_uri_home>s/versions"
    - label: "%<organization_label>s: %<project_label>s (feed)"
      mime: "application/atom+xml"
      relation: "self"
      uri: "%<project_uri_home>s/versions.xml"
tracker:
  uri: "https://github.com/%<project_owner>s/%<project_name>s/issues/%<id>s"

The above can be customized as follows:

  • avatar: Manages team member avatar details.

    • uri: Required. The URI format for linking to avatars as formatted using String Formats. Default: GitHub. The id is dynamically calculated via the external_id of the user stored in the Lode cache.

  • build: Manages build details.

    • basename: Required. The build file basename. Default: index. Used to customize the built file name.

    • format: Required. The build output format. Default: stream. Used to determine what format to build the release notes as. Multiple formats are supported.

    • layout: Required. The Hanami Views layout used when building release notes. Default: page. This can be disabled when using false or customized further — via your own XDG configuration — when providing your own templates and/or partials.

    • max: Required. The maximum number of Git tags to build. Default: 1. By default, you are limited to building release notes for changes (commits) since the last tag but you can increase the maximum to build release notes for as many tags as you like.

    • root: Required. The the root build directory. Default: tmp/milestones. This can be a relative or absolute path and defaults your current project. The path is automatically created if missing.

    • stylesheet: Required. The stylesheet basename which is only used by the web format. Default: page. This can be a relative path (i.e. ../page) which is especially handy when build max is set to a number greater than one so the release notes for each tag you build loads the stylesheet properly. The path is automatically created if missing.

  • commit: Manages commit categories, emojis, hyperlinks, and formatting.

    • categories: Required. Defaults to five categories which pairs well with the Git Lint gem. Category order is important with the first taking precedence over the second and so forth. Special characters are allowed for prefixes but should be enclosed in quotes. To disable categories, use an empty array. Example: categories: [].

      • emoji: Required. The emoji associated with the label for output purposes. Used by the ASCII Doc, Markdown, and stream build formats. Defaults to the provided emojis.

      • label: Required. Allows you to customize the category label. All commits are grouped by label which equates to the prefix, or first word, used in each commit message. The defaults pair well with the Git Lint gem. Defaults to the provided labels.

    • format: Required. Defines the default format used for rendering commit messages unless specified in the commit trailer metadata which takes higher precedence. Default: asciidoc.

    • uri: Required. The URI for linking to commits as formatted using String Formats. Default: GitHub. The id is dynamically calculated via the commit SHA of each commit analyzed at runtime.

  • generator: Manages generator details.

    • label: Required. The label of the generator used for all software milestones. Default: Milestoner.

    • uri: Required. The URI of the generator used for all software milestones. Defaults to Milestoner’s homepage URL as provided by the Gem Specification of this project.

    • version: Required. The version of the generator used for all software milestones. Defaults to Milestoner’s current version as provided by the Gem Specification of this project.

  • loaded_at: Required. Dynamically calculated when the configuration is loaded and is generally meant to represent current time. You can customize this value but is not recommended.

  • organization: Manages organization details.

    • label: Required. The organization’s label. Can be used within other keys via String Formats and is meant for branding purposes.

    • uri: Required. The organization’s home page URI. Can be used within other keys via String Formats.

  • profile: Manages team member profile details.

    • uri: Required. The URI format for linking to profiles as formatted using String Formats. Default: GitHub. The id is dynamically calculated via the handle of the user stored in the Lode cache.

  • project: Manages project details.

    • author: Required. The project author. Dynamically calculated by the Etcher gem in the following order: This value or Git configuration user name.

    • description: Optional. The project description. Dynamically calculated by the Etcher gem in the following order: This value, Gem Specification summary, or CFF abstract.

    • label: Optional. The project label. Dynamically calculated by the Etcher gem in the following order: This value, Gem Specification metadata label, or CFF title.

    • name: Required. The project name. Dynamically calculated by the Etcher gem in the following order: This value or Gem Specification name.

    • owner: Required. The project owner. This is your source code organization or user handle. Used when formatting URLs (mentioned above). Default: undefined. It is strongly recommended you configure this value so all links are formatted properly.

    • uri: Manages project URI details.

      • home: Required. The project home URI. Dynamically calculated by the Etcher gem in the following order: This value, Gem Specification homepage, or CFF URL.

      • icon: Optional. The project icon URI. Used for branding. For example, you could use an organization specific URI: "%<organization_uri>s/images/projects/%<project_name>s/favicon.ico".

      • logo: Optional. The project logo URI. Used for branding. For example, you could use an organization specific URI: "%<organization_uri>s/images/projects/%<project_name>s/logo.png".

      • version: Required. The project version URI. Defaults to the versions folder of your project home URI. This ensures all release notes link back to your project.

    • version: Required. The project version. Dynamically calculated based on the last Git tag of your project and Git Milestone commit trailer metadata. The default is: 0.0.0. For more on this see, the Automatic Versioning section below. You can configure a value but is not recommended since any custom value you supply will be used for all deployments and release notes. You’re better off letting this gem compute this for you.

  • review: Manages code review details.

    • uri: Required. The URI format for linking to code reviews as formatted using String Formats. Default: GitHub. The id is currently a placeholder for future feature support when API support is added. For now this links to all code reviews with the goal to link to individual code reviews based on Git Trailers.

  • syndication: Manages syndicated feed details when used with the feed build format.

    • categories: Required. Manages category details.

      • label: Required. The category label. Default: Milestones.

      • name: Required. The category name. Default: milestone.

    • entry: Required. Manages feed entry details which are the details of each Git tag.

      • label: Required. The entry label. Default: %<id>s. Automatically calculated, at runtime, for the current version.

      • uri: Required. The entry URI. The full URI to your project version. The default uses your project version URI. If customized, ensure you include %<id>s so the URI can properly link to the calculated version at runtime.

    • id: The ID of your feed which, per Atom specification, should be the the URI of your project (including version) which is why this defaults to your project version URI. If customized, ensure the %<id>s is included for proper runtime calculation.

    • label: The label of your feed and is what people will see when subscribing to your feed. Defaults to dynamic string formatting based on existing configuration values.

    • links: Required. Provides links to HTML and XML versions of your feed. This can be an array of links but generally you only need HTML and XML formats.

      • label: Required. The link label. Defaults to dynamic string formatting based on existing configuration values.

      • mime: Required. The mime type. Defaults to HTML and XML.

      • relation: Required. Identifies the relation of the link which can either be self (i.e. XML) or alternate (i.e. HTML).

      • uri: Required. The link URI to follow for more information. Defaults to dynamic string formatting based on existing configuration values.

  • tracker: Required. Manages issue tracker details.

    • uri: Required. The URI format for linking to issues as formatted using String Formats. Default: GitHub. The id is dynamically calculated via the commit Issue trailer as linted by Git Lint. When no ID can be found, this will default to All issues.

As hinted at above, all URIs (including syndication), support String Formats. This means you can use the %<key>s format — replacing key with the key of your choice — to customize your configuration further.

💡 If you need to know what your current configuration looks like, you can jump into your applications IRB console and inspect Milestoner::Container[:settings] to see full details.

Config

Usage

Milestoner can be configured via the command line using: milestoner config. This allows you to create, edit, view, and/or delete your global or local configuration as desired. The configuration is managed by the Runcom gem which is built atop the XDG gem for managing global or local configurations. Please read the documentation of each gem to learn more.

Cache

Usage

Milestoner’s cache allows you to enrich user information (i.e. authors, collaborators, etc) by storing information in a PStore database as managed by the Lode gem. Cache location, as with the Config, is managed by the Runcom gem.

User information should be sourced from whatever service used for managing your source code. For example, when using GitHub, your workflow might look like this:

milestoner cache --list
# 🟢 [milestoner] Listing users...
# 🟢 [milestoner] No users found.

milestoner cache --create "111,jsmith,Jane Smith"
# 🟢 [milestoner] Created: "Jane Smith"

milestoner cache --create "222,jdoe,John Doe"
# 🟢 [milestoner] Created: "John Doe"

milestoner cache --create "333,jgrey,Jill Grey"
# 🟢 [milestoner] Created: "Jill Grey"

milestoner cache --list
# 🟢 [milestoner] Listing users...
# External ID, Handle, Name
# -------------------------
# "111", "jsmith", "Jane Smith"
# "222", "jdoe", "John Doe"
# "333", "jgrey", "Jill Grey"

milestoner cache --delete "Jill Grey"
# 🟢 [milestoner] Deleted: "Jill Grey".

milestoner cache --list
# 🟢 [milestoner] Listing users...
# External ID, Handle, Name
# -------------------------
# "111", "jsmith", "Jane Smith"
# "222", "jdoe", "John Doe"

milestoner cache --info
# 🟢 [milestoner] Path: /Users/bkuhlmann/.cache/milestoner/database.store.

💡 Use https://api.github.com/users/<handle> to acquire the external ID for any GitHub user.

Once team member information is stored in your cache, you’ll be able to build release notes which automatically link to GitHub user information without constantly hitting the GitHub API. Users are identified by name so the full author name used for each commit message needs to match the same user name as stored in your source repository hosting service.

If you don’t use the cache, your release notes use a question mark (?) and unknown for team members as highlighted below:

Usage

Build

Usage

The build command allows you to quickly build release notes to check the current status of your project or deploy a new milestone. By default, the build command uses either the default or custom configuration as documented in the Configuration section above. This means, when using the defaults, you can immediately build the release notes for your project in a temporary directory:

milestoner build --format web
# 🟢 [milestoner] Building Milestoner (web)...
# 🟢 [milestoner] Built: /Users/bkuhlmann/Engineering/OSS/milestoner/tmp/milestones/page.css.
# 🟢 [milestoner] Built: /Users/bkuhlmann/Engineering/OSS/milestoner/tmp/milestones/index.html.

The above command is so useful that I use the following msw (i.e. Milestoner Web) Bash alias to build current release notes or release notes for several tags:

# Label: Milestoner (web)
# Description: Build milestone(s) in web format.
# Parameters: $1 (optional): Maximum tags to build. Default: 1.
msw() {
  local max=${1:-1}
  local root="tmp/milestones"
  local path="$root/index.html"

  rm -rf tmp/milestones

  if [[ "$max" == 1 ]]; then
    milestoner build --max "$max" --format web

    if [[ -f "$path" ]]; then
      open "$path"
    fi
  else
    milestoner build --max "$max" --stylesheet "../page" --format web

    if [[ -d "$root" ]]; then
      ruby -run -e httpd "tmp/milestones" --port 3030 &
      open "http://localhost:3030"
      fg
    fi
  fi
}

Check out the help documentation (i.e. milestoner build --help) for addition usage that explains what command line options you can use to overwrite the current configuration.

Commits

By default, all Git commit messages support ASCII Doc syntax but you can use Markdown too.

ASCII Doc is rendered using the Asciidoctor gem while Markdown is rendered using the Redcarpet gem. Regardless of what renderer you choose, each supports syntax highlighting via the Rouge gem. This also means you can customize the Rouge styles via the page.css template as documented in the Templates section below.

ℹ️ The Rouge CSS classes are slightly cryptic in terms of readability but you can see how they are applied when inspecting the HTML DOM.

Here’s a couple examples of commit messages using ASCII Doc and Markdown syntax:

ASCII Doc

ASCII Doc

Markdown

Markdown

💡 To see an example of what this renders to HTML as, see the Formats section below.

Sanitization

Sanitization of commit messages is handled by the Sanitize gem. This means you can only use a limited set of HTML elements (this includes ASCII Doc and Markdown rendering). Here’s what’s allowed:

The following global attributes are allowed for all elements:

The following attributes are limited to only a few elements like a, abbr, and dfn for the most part.

An additional set of attributes are allowed but are specific to each element and fairly limited. Ultimately, if you don’t see an attribute being rendered then it’s not allowed.

Trailers

Multiple Git Trailers for your commits are supported which are detailed in the linked article. At a minimum, the Milestone trailer is highly recommended since this is how Milestoner handles Automatic Versioning for you.

One of the more powerful features of using Git Trailers in your commit messages is they give you the ability to fully resolve what is defined in your default global configuration. Here’s a more detailed breakdown:

  • Format (optional): Use ascii_doc or markdown for the value to control what syntax used to render your commit message. The default is ascii_doc but if your configuration uses a different default you can override that per commit message if desired.

  • Issue (optional): When supplied, Milestoner will automatically associate your commit with the corresponding issue ID you provide as a value. This works in conjunction with your configuration.

  • Milestone (optional): This is detailed in the Automatic Versioning section below.

Automatic Versioning

As mentioned earlier, the calculation of version information happens automatically based on your last Git tag and any Git commit trailer metadata used. If none of this information is present, then the default version of 0.0.0 is used instead. All of this information is available to you via the following command:

milestoner build --help

Running the above will dynamically show you latest version information — along with help documentation — in case you have doubts. You can use this as a status check as well. If you don’t want to use the automatic version, you can override by using the --version option when building. Example:

# Uses automatic version.
milestoner build --format stream

# Uses manual version.
milestoner build --format stream --version 1.2.3

By default, automatic versioning is based on your last known Git tag. The version is bumped based on Git commit trailer information from untagged commits (i.e. commits created since the last tag). All of this is managed via the Versionaire gem. To ensure automatic versioning works properly, you only need to add the Milestone Git commit trailer with a value of: patch, minor, or major. Here’s an example assuming you have published Version 1.0.0:

# First commit.
Milestone: patch

# Second commit.
Milestone: minor

# Third commit
Milestone: patch

Given the above, the resulting version would be: 1.1.0. This is because the highest milestone was a minor milestone. The highest milestone wins and doesn’t matter how many commits you made with the same milestone trailer information or the order in which the commits were made. Here’s another example:

# First commit.
Milestone: patch

# Second commit.
Milestone: patch

# Third commit
Milestone: patch

Given the above, the resulting version would be: 1.0.1. This is because the highest milestone was a patch. Here’s a final example:

# First commit.
Milestone: major

# Second commit.
Milestone: minor

# Third commit
Milestone: patch

Given the above, the resulting version would be: 2.0.0. This is because the highest milestone was a major milestone.

Templates

Template functionality is powered by Hanami Views which means you can completely customize all build formats, templates, partials, stylesheets, images, and much more. The quickest way to start customization is to copy the templates folder structure — included with this gem — to your preferred Runcom configuration (i.e. global or local). For example, this gem’s template structure is:

lib/milestoner/templates
├── layouts
│  ├── page.adoc.erb
│  ├── page.html.erb
│  ├── page.md.erb
│  ├── page.stream.erb
│  └── page.xml.erb
├── milestones
│  ├── _avatar.adoc.erb
│  ├── _avatar.html.erb
│  ├── _avatar.md.erb
│  ├── _avatar.xml.erb
│  ├── _commit.adoc.erb
│  ├── _commit.html.erb
│  ├── _commit.md.erb
│  ├── _commit.stream.erb
│  ├── _commit.xml.erb
│  ├── _content.adoc.erb
│  ├── _content.html.erb
│  ├── _content.xml.erb
│  ├── _logo.adoc.erb
│  ├── _logo.html.erb
│  ├── _logo.md.erb
│  ├── _logo.xml.erb
│  ├── _none.adoc.erb
│  ├── _none.html.erb
│  ├── _none.xml.erb
│  ├── _profile.adoc.erb
│  ├── _profile.html.erb
│  ├── _profile.md.erb
│  ├── _profile.xml.erb
│  ├── _tag-insecure.html.erb
│  ├── _tag-secure.html.erb
│  ├── _tag.adoc.erb
│  ├── _tag.html.erb
│  ├── _tag.md.erb
│  ├── _tag.stream.erb
│  ├── _tag.xml.erb
│  ├── _user.adoc.erb
│  ├── _user.html.erb
│  ├── _user.md.erb
│  ├── _user.xml.erb
│  ├── _users.adoc.erb
│  ├── _users.html.erb
│  ├── _users.xml.erb
│  ├── show.adoc.erb
│  ├── show.html.erb
│  ├── show.md.erb
│  ├── show.stream.erb
│  └── show.xml.erb
└── public
   └── page.css.erb

This means you could, for example, copy all of Milestoner’s default templates to your own Runcom configuration and customize as you see fit. Example (using global configuration):

cp -r <milestoner_gem_root>/lib/milestoner/templates $HOME/.config/milestoner/templates

Milestoner searches your Runcom configuration first and, if templates are detected, will be used instead. Otherwise, Milestoner falls back to it’s own templates. Once Runcom has calculated all possible template locations, Hanami Views handles the final loading and rendering of the templates.

Formats

Of all build formats supported, the web format is the most powerful and feature rich. The following showcases some of the information rendered in this format based on commit activity.

Overview

ASCII Doc

With Valid Commit Signature

ASCII Doc

With Invalid Commit Signature

ASCII Doc

With Valid Tag

ASCII Doc

With Invalid Tag

ASCII Doc

With ASCII Doc/Markdown

ASCII Doc

💡 See Git Notes to learn more.

You’ll find all formats render similar information with the feed format being the closest but most formats are not as feature rich as the web format. Each milestone is meant to provide you with the right amount of statistical information you can make informed decisions.

Security

To securely sign your Git tags, install and configure GPG:

brew install gpg
gpg --gen-key

When creating your GPG key, choose these settings:

  • Key kind: RSA and RSA (default)

  • Key size: 4096

  • Key validity: 0

  • Real Name: <your name>

  • Email: <your email>

  • Passphrase: <your passphrase>

To obtain your key, run the following and take the part after the forward slash:

gpg --list-keys | grep pub

Add your key to your global (or local) Git configuration and ensure GPG signing for your tag is enabled. Example:

[tag]
  gpgSign = true
[user]
  signingkey = <your GPG key>

Now, when publishing a new milestone (i.e. milestoner --publish <version>), the signing of your Git tag will happen automatically. You will be prompted for the GPG Passphrase each time unless you are running the GPG Agent in the background (highly recommend).

Development

To contribute, run:

git clone https://github.com/bkuhlmann/milestoner
cd milestoner
bin/setup

You can also use the IRB console for direct access to all objects:

bin/console

Tests

To test, run:

bundle exec spec

Credits