Every GitHub repository shows three options when a pull request is ready to be merged:
The default is usually Create a Merge Commit, which produces history that becomes harder to read and reason about over time. And most teams tend to leave this default as-is.
This post covers what each strategy does, why Squash and Merge is a better default, and how to configure GitHub to enforce it.
Anyone can commit code to a repository pretending to be you. Git's author fields (user.name and user.email) are free-form text that any client can set to anything. Cryptographic commit signing closes that gap by mathematically binding a commit to a key pair that only you control. Once you add a verified badge to your commits on GitHub or GitLab, every reviewer can be confident that the code actually came from you.
This post walks through the full picture: why signing matters, how to configure your git client correctly, how to generate and publish a GPG key, how to use your platform's no-reply address so you never expose your real email, and how to automate Signed-off-by trailers with git hooks, complete with copy-paste examples for every step.
If you browse the commit history of a long-running project, you will find one of two things. Either a history that reads like a record, something you can actually use to understand why the code is the way it is, or something like this:
I have written commits like that. Most developers have. It happens when you treat the commit message as a formality, when the only audience you are writing for is the CI system that just needs to see something in the message field.
Compare that to this:
feat(datastore): add support for datastore clusters
fix(ssh): prevent IPv6 addresses from being double-wrapped in brackets
refactor(firmware): set firmware configuration during create
chore(deps): bump govmomi from 0.51.0 to 0.52.0
docs: update README with plugin installation instructions
feat(datasource): add virtual machine datasource
Which would you rather read?
The second log follows Conventional Commits, a lightweight specification that gives every commit a predictable, parseable shape. The difference is not talent or effort. It is convention.
This post is my attempt to explain how Conventional Commits work, why each rule exists, and how I use them in practice. A lot of this builds on Chris Beams's foundational piece, How to Write a Git Commit Message. If you have not read it, do that first. What follows extends the principles he outlines into the structured format I have settled on.
Every once in a while, someone asks me how this site works. The short answer: it is a static site generated by ProperDocs, themed with Materialx, deployed to GitHub Pages via GitHub Actions, with Cloudflare Pages serving pull request build previews and Cloudflare handling DNS for the custom domain. No CMS, no database, no runtime server. Every page is a Markdown file in a Git repository. Merges to main trigger the deploy workflow when paths that affect the site change.
This post walks through how all those pieces fit together, with the actual configuration files that run this blog today.
Every open-source project on GitHub eventually reaches the point where someone outside the immediate author wants to help. They open an issue that is missing half the information needed to reproduce it. They submit a pull request on the main branch that touches a dozen unrelated files. Or they send a message asking where to start.
A well-written CONTRIBUTING.md is the answer to all of those situations before they happen. It is the first thing a potential contributor reads when they want to get involved, and it sets the tone for every interaction that follows. Done right, it reduces back-and-forth, keeps the project moving, and signals to contributors that the project is organized and worth their time.
This post walks through how I write CONTRIBUTING.md files for my open-source projects: what goes in them, why each section matters, and how to write guidelines that contributors will actually follow.
setup-task: Install Task in GitHub ActionsIf you have been using Task (go-task/task) as your task runner and build tool, you have probably run into the same friction I did: getting it installed cleanly inside a GitHub Actions workflow is more annoying than it should be. There is no native support on GitHub-hosted runners, so you end up writing a curl one-liner, hand-rolling a cache step, or copy-pasting boilerplate across every workflow in every repository. It works, but it is not great.
tenthirtyam/setup-task is my solution to that problem. It is a purpose-built GitHub Action that handles downloading, caching, and configuring Task in a single step so you can get back to what actually matters: the tasks themselves.
I'm incredibly excited to announce the v2.0.0 release of vmware/packer-plugin-vmware.
This isn't just an incremental update; it's the culmination of months of dedicated effort to refactor, modernize, and refocus the plugin for the future.
Additionally, this is the first release of the plugin after the transfer of the project to Broadcom under the vmware GitHub organization.
🚀 Redefining the Plugin's Mission
The first and most significant change is a decision to refine the plugin's focus. Moving forward, the plugin will exclusively target the VMware Desktop Hypervisors: VMware Fusion Pro and VMware Workstation Pro.
For a long time, the plugin carried the maintenance burden of supporting VMware ESX. While this was useful in the past, the ecosystem has evolved. Broadcom provides the feature-rich Packer Plugin for VMware vSphere vmware/packer-plugin-vsphere which is purpose-built for vSphere environments. Continuing to maintain parallel ESX support in this plugin created a confusing user experience as well as split or duplicated development focus. By removing it, efforts will be dedicated to creating the best possible plugin experience for the desktop hypervisor user base.
Similarly, support is removed for the Workstation Player which has reached end-of-availability.
This sharpened focus is the bedrock upon which the release is built, enabling a more stable, feature-rich, and maintainable plugin.
✨ Enhancements
The release will introduces some highly requested features that unlock new and more efficient workflows.
The development and maintenance of the the following Packer plugins have been transferred from HashiCorp to Broadcom under the github.com/vmware organization as of January 27, 2026 🥳 🎉
vmware/vsphere)vmware/vmware)No changes are required in your configurations and plugin initialization will be automatically redirected from github.com/hashicorp/packer-plugin-vmware to github.com/vmware/packer-plugin-vmware. However, we encourage you to consider updating your configurations to source from vmware/ from hashicorp/ in the packer block.
Over the past few years, Broadcom has established a valuable partnership with the Packer team at HashiCorp, and we're incredibly grateful for their contributions and continued guidance.
This transition underscores the dedication to the plugin and our commitment to:
Continuing development: We're eager to invest in the plugin's future, bringing new features and improvements to better serve your needs.
Maintaining stability: We will continue to iterate to enhance the plugin's stability and reliability for your image automation workflows.
Fostering community engagement: We highly value your feedback and look forward to collaborating with you on the plugin's evolution.
As the maintainer for these plugins, I'm excited about this next step and the opportunity to further enhance the plugin in collaboration with you.
Please update to v2.1.1 to address the issue observed in issue 651.
I'm incredibly excited to announce the v2.1.0 release of vmware/packer-plugin-vsphere.
Below are the highlights for the release:
✨ Enhancements
datastore_cluster) for virtual machine builds and post-processing.vsphere-virtualmachine)for querying virtual machine information, enabling vsphere-clone to select a template.override (bool) option to the vsphere-template post-processor, allowing the overwrite of an existing template if set to true.tools_sync_time to ensure more flexible and accurate time synchronization settings for virtual machines.🐛 Bug Fixes
vsphere-supervisor Jenkins template to address compatibility.Disclaimer
This content is provided for historical reference and may no longer reflect current guidance or best practices.
The VMware Cloud Foundation Async Patch Tool is a command-line tool that enables you to perform asynchronous patching on a VMware Cloud Foundation instance. This enable you to apply patches that are not part of a VMware Cloud Foundation release but are required to address a specific issue, such as a security vulnerability.
Recently, I was asked to assist a couple customers with automating the process of applying async patches to their VMware Cloud Foundation instance. The customers were already using PowerShell to automate other tasks, including using some of our open source PowerShell modules and wanted to continue using PowerShell to automate the async patching process if possible.
This article provides examples of using the Async Patch Tool with PowerShell. The examples are based on the following:
--SKU VCF).