Forem: Steven Marks

Ditch the Manual Chore: Automating Releases and Versioning with release-please

Steven Marks — Tue, 04 Nov 2025 08:25:18 +0000

I love coding, I love seeing new features come to life, and I genuinely enjoy writing documentation (I know, weird right?). But if there's one part of the development lifecycle that consistently makes me want to scream into my pillow, it's the tedious, error-prone chore of creating a new release.

Updating the version number manually? Check.
Scouring Git history to draft a meaningful CHANGELOG.md? Check.
Forgetting a fix and having to immediately push a v1.2.1-fix-for-the-fix patch? Absolutely check.

If you've been following my journey on automating my workflows, you'll know that I'm a huge believer in moving the mundane to the machine. I previously discussed streamlining development using Semantic Release and Commitizen in my article, Automated release with Semantic Release and Commitizen. This approach dramatically cleaned up commit messages and helped determine the correct version bump.

However, over time I have found that with semantic-release, there are some limitations if you are trying to move over to trunk based development and are not in a position to use feature flags.

The missing piece? release-please.

What is `release-please` and How Does It Improve the Workflow?

release-please is an open-source tool developed by Google, primarily implemented as a GitHub Action, that takes over the final, messy steps of the release process.

The fundamental improvement over a self-hosted Semantic Release setup is simple:

Approach	Old Way (Semantic Release/Custom Script)	New Way (`release-please` Action)
Trigger	Manual command or a final merge/tag event.	Continuously tracks changes on the main branch.
Release Artifacts	Generated by script, then pushed/tagged manually or via subsequent CI job.	Manages a Perpetual Release PR for instant preview.
Human Action	Manually run a command/pipeline and hope it works.	Merge the Release PR to confirm and publish.

The core of release-please is that it constantly maintains a living, breathing view of your next release right inside your GitHub Pull Requests tab, operating entirely on the principles of Conventional Commits.

The Core Logic: Commits to Versions

The tool reads the commit history on your main branch to determine the exact nature of the change:

Commit Type	Semantic Version Impact	Example of Change
`fix:`	PATCH (0.0.x)	A backward-compatible bug fix.
`feat:`	MINOR (0.x.0)	A new, backward-compatible feature.
`feat!:` or `BREAKING CHANGE:` in footer	MAJOR (x.0.0)	An incompatible API change.

You stop having to worry about which version number to apply; you just commit changes with accurate commit messages, and release-please figures out the rest.

How does it work?

First off, it's important to know that release-please will not trigger a release if there is nothing to release! If no new feat or fix commits have landed, it just sits tight.

When it does have work to do, here’s the flow:

Detect Changes: The action runs (either on a schedule or when I push to the main branch) and scans the repository's history to find all the changes since the last release tag.
Analyse Commits: It then analyzes all the commit messages, looking for Conventional Commit keywords (like feat, fix, chore, or BREAKING CHANGE) to categorize everything that's happened.
Determine Version Bump: Based on those commits, it automatically determines the correct semantic version bump (major, minor, or patch).
Generate Release PR: This is the best part. The action creates (or updates) a special Pull Request. This PR contains the new version number bumped in files like package.json and, crucially, a fully generated changelog based on all the commits it found.
Merge Release PR: Once I've reviewed that PR and I'm happy it looks correct, I just merge it into the main branch. This merge event is the trigger for the next step.
Publish Release: Merging the PR kicks off another workflow that creates the official Git tag, drafts the formal GitHub release (using the changelog), and publishes the new version to package registries, like npm for my JavaScript projects.

Implementation: Configuration and Action

Getting started is surprisingly simple and requires minimal configuration for most projects.

1. Configuration File (`release-please-config.json`)

For most projects, defining a single file to tell the tool what type of project it is, is enough. This example sets up a generic project, ensuring the tool knows where to look for version updates.

{
  "release-type": "simple",
  "include-v-in-tag": true
}

2. Manifest file (`.release-please-manifest.json`)

The manifest file tracks the version that the project is currently on, for existing projects enter the latest release tag, for a new project use 0.0.0 to tell release-please its a new project.

{
  ".": "0.0.0"
}

3. The Github Action

The core of the implementation lives in your repository's CI/CD pipeline, often in a file named .github/workflows/release-please.yaml. This action needs the appropriate permissions to create the release artifacts (PRs, Tags, and GitHub Releases).

name: Release Please

on:
  push:
    branches:
      - main

permissions:
  # The 'write' permission is essential for creating/updating the release PR,
  # creating the Git tag, and publishing the GitHub release.
  contents: write
  pull-request: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: google-github-actions/release-please-action@v4
        with:
          # Use your configuration file
          config-file: release-please-config.json
          manifest-file: .release-please-manifest.json
          # a PAT is needed if you need to re-run tests against an existing PR
          token: ${secrets.MY_PAT}

Once this action is merged and runs, your release automation will be live. Say goodbye to the manual version bump chore. 👋

4. Hooks with release-please

When a release is created its likely you would want to run additional jobs after it.

If you would like to trigger another job after release is created, you need to propagate outputs from the step to the job:

jobs:
  release-please:
    runs-on: ubuntu-latest
    outputs:
      tag_name: ${{ steps.release.outputs.tag_name}}
      release_created: ${{ steps.release.outputs.release_created}}
    steps:
      - uses: googleapis/release-please-action@v4
        id: release
        with:
          token: ${{ secrets.MY_PAT }}
          config-file: release-please-config.json
          manifest-file: .release-please-manifest.json

5. Trigger additional workflows

Creating the release PR is only half the battle. The real value comes from using it to trigger our staging pipeline, allowing for proper user testing before the release is finalised.

We want to build and push a new 'release candidate' (RC) image to our container registry every time the release-please PR is opened or updated. This ensures our staging environment always has the very latest proposed code.

To do this, we can create a separate GitHub Actions workflow that listens to pull_request events on the main branch. The magic lies in adding a condition to ensure it only runs for PRs created by release-please.

Here is the complete workflow file:

name: Create Staging artifact from Release PR

on:
  pull_request:
    types: [opened, synchronize]
    branches:
      - "main"

jobs:
  build-and-deploy-staging:
    runs-on: ubuntu-latest
    # This 'if' condition is the key:
    # It checks that the source branch name starts with the prefix
    # used by release-please.
    if: startsWith(github.head_ref, 'release-please--')
    permissions:
      contents: read
      id-token: write # Assuming auth with GCP/AWS/Azure
    steps:
      - name: Checkout code from PR
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}

      - name: 📝 Extract version from manifest file
        id: extract_version
        run: |
          # Example output: 1.1.0
          VERSION=$(jq -r '.["."]' .github/release-please-manifest.json)
          echo "version=${VERSION}" >> $GITHUB_OUTPUT

      - name: 🔢 Calculate Next Staging Tag
        id: calculate-staging-tag
        run: |
          set -eo pipefail
          # The base version (e.g., 1.1.0) from the previous step
          BASE_VERSION="${{ steps.extract_version.outputs.version }}"
          # Assumes IMG env var is set (e.g., ghcr.io/my-org/my-repo)
          IMAGE_NAME="${{ env.IMG }}"

          echo "Base version detected: $BASE_VERSION"

          # 1. Query registry for existing tags matching the pattern X.Y.Z-rc.N
          # We search for tags like '1.1.0-rc.1', '1.1.0-rc.2', etc.
          # This example uses gcloud, adjust for your registry (e.g., 'az acr', 'docker search')
          TAGS=$(gcloud container images list-tags "$IMAGE_NAME" \
            --format="json(tags)" \
            --filter="tags~^${BASE_VERSION}-rc\.[0-9]+$" 2>/dev/null || echo "[]")

          # 2. Determine the next sequential number
          if [ "$TAGS" == "[]" ]; then
              # No matching tags found, start at .1
              NEXT_NUM=1
              echo "No previous rc tags found. Starting at rc.1."
          else
              # Extract the number from tags, sort numerically, and take the highest
              MAX_NUM=$(echo "$TAGS" | jq -r --arg V "$BASE_VERSION" '.[] | .tags[] | select(startswith($V + "-rc.")) | split(".")[-1] | tonumber' | sort -rn | head -n 1)

              if [ -z "$MAX_NUM" ] || [ "$MAX_NUM" -eq 0 ]; then
                  NEXT_NUM=1
              else
                  # Increment the highest number found
                  NEXT_NUM=$((MAX_NUM + 1))
              fi
              echo "Highest previous rc number found: ${MAX_NUM}. Next number is: ${NEXT_NUM}"
          fi

          # 3. Output the final tag (e.g., 1.1.0-rc.2)
          NEW_TAG="${BASE_VERSION}-rc.${NEXT_NUM}"
          echo "NEW_TAG=${NEW_TAG}"
          echo "staging_tag=$NEW_TAG" >> $GITHUB_OUTPUT

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Build and Push Staging Image
        uses: docker/build-push-action@v6
        with:
          push: true
          tags: ${{ env.IMG }}:${{ steps.calculate-staging-tag.outputs.staging_tag }}
          platforms: linux/amd64
          cache-from: type=gha
          cache-to: type=gha,mode=max

Let's quickly break down the most important parts:

The if condition: if: startsWith(github.head_ref, 'release-please--') is the controller. It ensures this expensive build job only runs on pull requests opened by release-please, not on regular developer feature branches.
Extract version: This step reads the .github/release-please-manifest.json file to find out what version release-please is proposing (e.g., 1.1.0).
Calculate Next Staging Tag: This is the core logic. It asks the container registry "What is the highest rc tag you have for version 1.1.0?" If it finds 1.1.0-rc.1, it will output 1.1.0-rc.2. If it finds nothing, it starts at 1.1.0-rc.1. This ensures that every push to the PR (e.g., a fix) generates a new, unique, and sequential artifact.

With this workflow in place, we now have a fully automated process: a developer merges a feature, release-please creates a PR, and that PR automatically triggers a new staging build, ready for testing.

The Great Debate: To Squash or Not to Squash?

When you automate releases based on commit history, the question of how you merge feature branches becomes critically important.

The goal is a version history that is both clean for maintainers (Google's reasoning) and descriptive for developers (my reasoning).

The Case for Linear History (Squash-Merge)

Many organisations, including Google, advocate for using squash-merges to maintain a linear Git history. Their reasons often centre on maintenance efficiency:

Clean History: The main branch remains uncluttered, showing only one logically grouped commit per feature or bug fix.
Simpler Tooling: Tools like git bisect (for tracking down which change introduced a bug) work flawlessly because every commit is guaranteed to be a passing, production-ready state.
Changelog Control: Internal commits like a small fix introduced during feature development are irrelevant to the release notes as they were never experienced on the main branch. Squashing hides this noise from the public-facing CHANGELOG.md.

The Counter-Argument (Logical Merging)

While the logic for a clean history is sound, many developers, myself included, find monolithic squash commits challenging to work with:

Context is King: When you squash all feature branch commits into one, you risk losing the detailed context of where the fix or feature was applied. This forces one to scroll a lot to find context, which is "not good."
Descriptive History: A small number of logically grouped commits provides a history that is both informative and manageable. We should strive for fewer commits, but use "common sense" to combine them into fewer, more meaningful entries.

The Recommended Hybrid Approach

The great news is that release-please is flexible enough to accommodate both philosophies.

For maximum simplicity and tool compatibility (The Squash Style): Use squash-merge. Crucially, leverage the commit message's body to include all relevant feat: and fix: messages using footers. release-please is smart enough to parse multiple changes from a single monolithic commit:
```
feat: adds v4 UUID to crypto

This adds support for v4 UUIDs to the library.

fix(utils): unicode no longer throws exception
  BREAKING-CHANGE: encode method no longer throws.
```

The additional messages must be added to the bottom of the commit body.

For maximum contextual integrity (The Logical Style): Use a merge commit or a rebase merge that retains your carefully crafted atomic commits. As long as every commit landing on main strictly follows the Conventional Commit specification, release-please will aggregate all of them when generating the Release PR.

This small automation is a huge step forward. It completely eliminates the non-coding task of versioning and changelog management, allowing you to focus on developing features and fixing bugs.

Automated release with Semantic Release and commitizen

Steven Marks — Mon, 09 Oct 2023 19:46:46 +0000

When working with JavaScript projects, managing version numbers and commit messages is important for the maintainability of the project. Since 2020 I have been the main developer of Atomic Calendar Revive a highly customisable Home Assistant calendar card, I found maintaining versions and releases to be cumbersome until recently. In this article, I will introduce the commitizen and semantic-release packages for creation or appropriate commit messages and semantic versioning. I will also provide examples of how I am currently using these packages to streamline my release workflow and project maintenance.

The old days

Starting out I had never developed a project like this in TypeScript, I had only ever worked on Python projects, So I was running yarn run build which would run rollup, build my js files into a dist folder, I would then commit the changes to a branch, create a PR, merge the PR then manually tag the new version and create the release on GitHub.

As you can see there are quite a few manual steps to achieve this which took too much time, time I could be spending on new features or bug fixes.

I knew there had to be a better way to do this, there was no way large teams were wasting this much time on releases and as a small one person dev, its even more important to save as much time as possible.

What is Semantic-release and how does it work?

semantic-release uses the commit message to determine the impact of changes in the codebase, with this it is able to automate updating the version number correctly and managing the release process for the project.

Semantic-release performs the following basic operations:

Analyses commit messages to determine whether a new version is required.
If a new version is required, automatically determines the appropriate version number.
Updates the CHANGELOG file and creates the relevant Git tag.
Publishes a github release if required
Publishes the new version to the package manager if required.

There are many other actions that it can perform via a great plugin architecture, so these are not limited to github / npm.

What is Commitizen and how does it work?

commitizen helps developers write commit messages in the same format, this also ensures that all commit messages follow the semantic versioning requirements.

Commitizen provides an interactive interface that prompts developers for specific information relating to that change, it then generates the commit message in the correct format, ensuring compatibility with semantic versions which ensures semantic-release can read the commit messages as expected.

How to setup Semantic-release and Commitizen

Below is a guide on how to use Semantic-release and Commitizen packages in your project, these are settings that I currently use but you can amend them to better suit your project.

Install Semantic-release and Commitizen packages

npm install --save-dev semantic-release commitizen cz-conventional-changelog

If you find you are unable to use the git cz command after using the above install try this:

npm install -g commitizen

This will install commitizen globally which seems to resolve the issue.

Create a configuration file for semantic-release (.release.rc, release.config.js or package.json) an example of how I use package.json:

"release": {
 "plugins": [
  [
   "@semantic-release/commit-analyzer",
   {
    "preset": "conventionalcommits"
   }
  ],
  [
   "@semantic-release/release-notes-generator",
   {
    "preset": "conventionalcommits"
   }
  ],
  [
   "@semantic-release/npm",
   {
    "npmPublish": false
   }
  ],
  [
   "@semantic-release/exec",
   {
    "prepareCmd": "yarn run build"
   }
  ],
  "@semantic-release/changelog",
  [
   "@semantic-release/git",
   {
    "assets": [
     "package.json",
     "changelog"
    ],
    "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
   }
  ],
  [
   "@semantic-release/github",
   {
    "assets": [
     {
      "path": "dist/atomic-calendar-revive.js"
     }
    ]
   }
  ]
 ]
}

This configuration file contains settings used for semantic-release. Lets break this down:

@semantic-release/commit-analyzer: Analyses commit messages and determines how the version number should be incremented (major, minor, patch). I use the conventional commits format so set the preset to inform commit-analyzer, this will look out for the ! to signify breaking changes etc.
@semantic-release/release-notes-generator: Generates the release notes based on commit messages related to the new version.
@semantic-release/npm: Updates the package.json file and publishes to the NPM package manager, I don't publish to NPM manager so disabled this but i do need package.json updating with the latest version.
@semantic-release/exec: This executes a command, in this case it will build my project ready for uploading to GitHub.
@semantic-release/changelog: Creates or updates a CHANGELOG file based on the generated release notes.
@semantic-release/git: Commits changes related to the new version to the git repository and creates the relevant git tag. I use this to commit the updated package.json into git and it also adds a commit message.
@semantic-release/github: Publishes the new version to GitHub and creates the related GitHub release. I also upload the file generated by @semantic-release/exec

Configure the cz-conventional-changelog adapter in package.json

{
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    }
  }
}

Configure CI / CD, I use Github Actions in the below example:

name: Release

on:
  push:
    branches:
      - master
      - beta
  workflow_dispatch:
jobs:
  release:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Setup Node.js
      uses: actions/setup-node@v2

    - name: Install dependencies
      run: yarn install

    - name: Run Semantic Release
      run: npx semantic-release
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

How to use semantic-release and commitizen

Commitizen

Simply run git add . then git cz, this command will run the interactive interface of Commitizen and ask you to write a properly formatted commit message.

Semantic Release

Semantic release by default uses the following branches:

master Regular releases to the default distribution channel
N.N.x or N.x.x or N.x with N being a number Regular releases to a distribution channel matching the branch name from any existing branch with a name matching a maintenance release range
next Regular releases to the next distribution channel
next-major Regular releases to the next-major distribution channel
beta (pre-release) pre-releases to the beta distribution channel
alpha (pre-release) pre-releases to the alpha distribution channel from the branch

You don't need to use all of these branches, for example I currently only use the beta and master branches, All my development happens in beta, on commit it releases a pre-release version then once i'm happy its working I merge beta into master which will create the latest production release.

How are version numbers determined from commit messages

Semantic release wil analyze the commit message to determine what the new version number should be. This process works by analysing the words and prefixes in the commit message. Commitizen facilitates this by ensuring the conventional commits format is followed.

The conventional commit format states that commit messages should be formatted as follows:

<type>([optional scope]): <summary>

[optional body]

[optional footer(s)]

type: Indicates the type of change (e.g., fix, feat, chore, docs, refactor, test, etc.).
[optional scope] (optional): Describes the part of the project that the change is applied to.
summary: A concise description of the change.
[optional body] (optional): A more detailed description of the change if required.
[optional footer(s)] (optional): Add tags to issues / reviewers etc.

Semantic-release uses this information to determine how to update the version number:

If at least one of the commit messages is feat type, the new version number will be subject to a “minor” increase (0.1.0).
If at least one of the commit messages contains BREAKING CHANGE in the body or ! after the type, the new version number will be subject to a major increase (1.0.0).
In other cases, especially if at least one of the commit messages is fix type, the new version number will be subject to a patch increase (0.0.1).

Final Thoughts

With the help of semantic-release and commitizen packages, you can increase the quality and maintainability of your project by using automated versioning and creating appropriate, easy to understand commit messages. Due to this being compatible with CI/CD it also makes the development process more efficient saving precious time to be spent on improving the project or drinking coffee.

Automating deployments using Terraform with Proxmox and ansible

Steven Marks — Sun, 04 Jun 2023 20:23:16 +0000

Over the years my home lab has grown and become more and more difficult to maintain, especially because some servers I build and forget as they function so well.

I have found recently though that moving to newer versions of operating systems can be difficult for the servers that I cant easily containerise at the moment.

For this reason I have moved over to using Terraform with Proxmox and ansible.

Telemate developed a Terraform provider that maps Terraform functionality to the Proxmox API, so start by defining the use of that provider in provider.tf

terraform {
  required_version = ">=0.13.0"

  required_providers {
    proxmox = {
      source  = "telmate/proxmox"
      version = "2.9.14"
    }
  }
}

provider "proxmox" {
  # Configuration options
  pm_api_url = var.proxmox_api_url
  pm_api_token_id = var.proxmox_api_token_id
  pm_api_token_secret = var.proxmox_api_token_secret

  # Optional: skip TLS Verification
  pm_tls_insecure = true
  pm_parallel     = 2
  pm_timeout      = 1200
}

Here we see two sections, the first of which contains the configuration for Terraform, it specifies the version of Terraform that is required along with all of the required providers and their required versions.

The second section contains the provider itself, and the configuration, a full list of arguments can be found here

A provider is a plugin that allows Terraform to manage external APIs (such as proxmox)

Now this is no good without some servers or "resources", I create a file per resource for my lab, this keeps it simple for me, however you may want to do this differently depending on your requirements. Create a file with the resource name bastion.tf There is a lot more going on in this file, so I have added comments to it.

# Specify the resource type, and then the name
resource "proxmox_vm_qemu" "bastion" {

  name = "td-bast01" # Name to call the VM
  desc = "Bastion" # Description for the VM
  target_node = var.proxmox_host # Proxmox target node

  clone = var.template_name  # The name of the template that this resource will be created from

  agent = 1 # is the qemu agent installed?

  os_type = "cloud-init" # The OS type of the image clone
  cores = 2 # number of CPU cores
  sockets = 1 # number of CPU sockets
  cpu = "host" # The CPU type
  memory = 4096 # Amount of memory to allocate
  onboot = true # start the VM on host startup
  scsihw = "virtio-scsi-pci" # Scsi hardware type
  bootdisk = "scsi0" # The boot disk scsi

  # This section contains the disk configuration, it can be duplicated for additional disks
  disk {
    size = "30G"
    type = "scsi"
    storage = "local-thin"
    iothread = 0
  }

  # if you want two NICs, just copy this whole network section and duplicate it
  network {
    model = "virtio"
    bridge = "vmbr0"
    tag = 20
  }

  ipconfig0 = "ip=172.16.20.43/24,gw=172.16.20.1"
  nameserver = "172.16.20.1"

  serial {
    id = 0
    type = "socket"
  }
  # sshkeys set using variables. the variable contains the text of the key.
  sshkeys = <<EOF
  ${var.ssh_key}
  EOF

  # Terraform has provisioners that allow the execution of commands / scripts on a local or remote machine.
  # Here I execute a command to update the VM.
  provisioner "remote-exec" {
    inline = ["sudo apt update", "sudo apt upgrade -y", "echo Done!"]

    connection {
      host        = "172.16.20.43"
      type        = "ssh"
      user        = "ubuntu"
      private_key = file(var.private_key_path)
    }
  }
  # Here I execute an ansible playbook to configure the VM.
  # I specify ANSIBLE_HOST_KEY_CHECKING as if run a second time and the VM is rebuil ansible wont connect unless this is set to false.
  provisioner "local-exec" {
    command = "ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook -u ${var.ansible_user}  -l bastion -i ../ansible-deploy/inventory --private-key ${var.private_key_path} -e 'pub_key=${var.public_key_path}' --ssh-extra-args '-o UserKnownHostsFile=/dev/null' ../ansible-deploy/main.yml"
  }
}

Through all of the files creates you will have noticed variables have been used against various configuration parameters, before they will work they need to be defined in a file, we will call this vars.tf

# provider vars
variable "proxmox_api_url"{
  type = string
}

variable "proxmox_api_token_id" {
  type = string
}

variable "proxmox_api_token_secret" {
  type = string
}

# resource vars
variable "proxmox_host" {
  type = string
  default = "td-vh01"
}
variable "template_name" {
  type = string
  default = "jammy-template"
}
variable "ansible_user"{
  default = "ubuntu"
  type = string
}

variable "private_key_path"{
  type = string
}

variable "public_key_path"{
  type = string
}

variable "ssh_key" {
  type = string
  default = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINm8L9RZ4lDsRDm6Zx7jqOrQx9mO7FphqcrV5teyGVJN"
}

Now that we have defined the variables create a credential file to store all our variable information:

proxmox_api_url = "https://127.0.0.1:8006/api2/json"
proxmox_api_token_id = ""
proxmox_api_token_secret = ""
private_key_path = "~/.ssh/id_ed25519"
public_key_path = "~/.ssh/id_ed25519.pub"
ansible_user = ""

Don't commit this file to Git as it contains sensitive information

Any variables in vars.tf that have a default value don't need to be defined in the credential file if the default value is sufficient.

The Cloud-Init template

The configuration that is used utilises a cloud-init template, check out my previous post (Proxmox template with cloud image and cloud init) where I cover how to set this up for use in Proxmox with Terraform.

Usage

Now all of the files we require are created, lets get it running:

Install Terraform and Ansible
```
apt install -y terraform ansible
```
Enter the directory where your Terraform files reside
Run terraform init, this will initialize your Terraform configuration and pull all the required providers.
Ensure that you have the credential.auto.tfvars file created and with your variables populated
Run terraform plan -out plan and if everything seems good terraform apply.

Use terraform apply --auto-approve to automatically apply without a prompt

To destroy the infrastructure, run terraform destroy

Final Thoughts

There is so much more potential using Terraform and Ansible. I have just scratched the surface, but you could automate everything up to firewall configuration as well, this is something I still need to look into, but it would be great to deploy and configure the firewall based on each individual device.

If you have any cool ideas for using Terraform and Ansible please let me know in the comments below!

Until next time...

Proxmox Template with Cloud Image and Cloud Init

Steven Marks — Sat, 03 Jun 2023 22:02:57 +0000

Using Cloud images and Cloud init with Proxmox is the quickest, most efficient way to deploy servers at this time. Cloud images are small cloud certified that have Cloud init pre-installed and ready to accept configuration.

Cloud images and Cloud init also work with Proxmox and if you combine this with Terraform you have a fully automated deployment model.

Guide

Download image

First you will need to choose an Ubuntu Cloud Image

Rather than downloading this, copy the URL.

Then SSH into your Proxmox server and run wget with the URL you just copied, similar to below:

wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img

This will download the image onto your proxmox server ready for use.

Install packages

The qemu-guest-agent is not installed on the cloud-images, so we need a way to inject that into out image file. This can be done with a great tool called virt-customize this is installed with the package libguestfs-tools. libguestfs is a set of tools for accessing and modifying virtual machine (VM) disk images.

Install:

sudo apt update -y && sudo apt install libguestfs-tools -y

Install qemu-guest-agent into the downloaded image:

sudo virt-customize -a jammy-server-cloudimg-amd64.img --install qemu-guest-agent --run-command 'systemctl enable qemu-guest-agent.service'

You can also install other packages at this point.

Adding users to the image (Optional)

It is possible to also add a user and SSH keys with the virt-customize. This is useful for automation such as terraform.

sudo virt-customize -a jammy-server-cloudimg-amd64.img --run-command 'useradd simone'
sudo virt-customize -a jammy-server-cloudimg-amd64.img --run-command 'mkdir -p /home/simone/.ssh'
sudo virt-customize -a jammy-server-cloudimg-amd64.img --ssh-inject simone:file:id_ed25519.pub
sudo virt-customize -a jammy-server-cloudimg-amd64.img --run-command 'chown -R simone:simone /home/simone'

Adds the user to the image
Makes the SSH Key directory
Injects the SSH Key. simone is the user the key will apply to, file:id_ed25519.pub is the file on the local host where the SSH Key is located
Makes sure the user simone owns the home folder

Create a virtual machine from the image

Now we need to create a new virtual machine:

qm create 9000 --memory 2048 --core 2 --name jammy-template --net0 virtio,bridge=vmbr0

Import the downloaded Ubuntu disk to the correct storage:

qm importdisk 9000 jammy-server-cloudimg-amd64.img local-lvm

Attach the new disk as a SCSI drive on the SCSI Controller:

qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0

Add cloud init drive:

qm set 9000 --ide2 local-lvm:cloudinit

Make the could init drive bootable and restrict BIOS to boot from disk only:

qm set 9000 --boot c --bootdisk scsi0

Add serial console:

qm set 9000 --serial0 socket --vga serial0

Turn on guest agent:

qm set 9000 --agent enabled=1

DO NOT POWER ON THE VM
{: .prompt-warning }

Convert the VM to a Template

Now, Create a template from the image you just created:

qm template 9000

Clone the template to a VM

Now you have a fully functioning template, which can be cloned as much as you want. But it makes sense to set some of the settings.

First, clone the VM (here we are cloning the template with ID 9000 to a new VM with ID 999):

sudo qm clone 9000 999 --name test-cloud-init

Next, set the SSH keys (if you didn't add yours earlier) and IP address:

sudo qm set 999 --sshkey ~/.ssh/id_rsa.pub
sudo qm set 999 --ipconfig0 ip=10.10.1.20/24,gw=10.10.1.1

It’s now ready to start up!

sudo qm start 999

You should be able to log in without any problems (after trusting the SSH fingerprint). Note that the username is ubuntu, for the key set here. If you added your own user earlier, you can use that instead

ssh ubuntu@10.10.1.1

Once happy with the template, you can stop the VM and clean up the resources:

sudo qm stop 999 && sudo qm destroy 999
rm jammy-server-cloudimg-amd64.img

References

https://registry.terraform.io/modules/sdhibit/cloud-init-vm/proxmox/latest/examples/ubuntu_single_vm

Closing

Hopefully this information was useful for you, If you have any questions about this article and share your thoughts head over to my Discord.

Forem: Steven Marks

Ditch the Manual Chore: Automating Releases and Versioning with release-please

What is release-please and How Does It Improve the Workflow?

The Core Logic: Commits to Versions

How does it work?

Implementation: Configuration and Action

1. Configuration File (release-please-config.json)

2. Manifest file (.release-please-manifest.json)

3. The Github Action

4. Hooks with release-please

5. Trigger additional workflows

The Great Debate: To Squash or Not to Squash?

The Case for Linear History (Squash-Merge)

The Counter-Argument (Logical Merging)

The Recommended Hybrid Approach

Automated release with Semantic Release and commitizen

The old days

What is Semantic-release and how does it work?

What is Commitizen and how does it work?

How to setup Semantic-release and Commitizen

How to use semantic-release and commitizen

Commitizen

Semantic Release

How are version numbers determined from commit messages

Final Thoughts

Automating deployments using Terraform with Proxmox and ansible

The Cloud-Init template

Usage

Final Thoughts

Proxmox Template with Cloud Image and Cloud Init

Guide

Download image

Install packages

Adding users to the image (Optional)

Create a virtual machine from the image

Convert the VM to a Template

Clone the template to a VM

References

Closing

What is `release-please` and How Does It Improve the Workflow?

1. Configuration File (`release-please-config.json`)

2. Manifest file (`.release-please-manifest.json`)