Release and publish a new PHP SDK version automatically: a step-by-step guide
Length:
8 min
Published:
September 25, 2023

Keeping a changelog tidy, tagging a new version of an SDK, then pushing it to a package repository. These are repetitive chores, and every one of them can be automated. That gives your developers back time they would otherwise spend on bookkeeping.
This tutorial shows you how to set that up. You will go through three steps:
- Create a Packagist account and register your SDK.
- Store your Packagist username and API token securely in GitHub.
- Set up a GitHub Action that releases and publishes each new SDK version.
Prerequisites
You already have a working SDK and you have pushed it to a GitHub repository.
Create a Packagist account and register your SDK
Before you publish your SDK for the first time, create a Packagist account here. Pick a name for your SDK that follows the Packagist naming convention. Then submit the package by entering the URL of your public GitHub repository.
Set up credentials
To publish your SDK to Packagist on your behalf, GitHub needs your Packagist username and API token. You can store both securely in GitHub.
- Open the Profile section on Packagist. Your username sits at the top of the page. Click Show API Token and copy the token.
- Open your project on GitHub. Go to Settings > Security > Secrets and Variables > Actions and click "New repository secret".
- Enter
PACKAGIST_USERNAMEin the Name field. - Enter your Packagist username in the Secret field. Click "Add secret" to confirm.
- Create one more secret. This time enter
PACKAGIST_TOKENin the Name field and paste the token from Step 1 into the Secret field. Add this secret.
Release and publish a new version
Set up a GitHub Action to release a new SDK version
To avoid updating the changelog and tagging versions by hand, we recommend the GitHub Action release-please. It tracks code changes since the last release and keeps a pull request open with the changelog and version bump, based on your commit messages. When you want to ship a new version, you merge that pull request.
The workflow below also publishes the new version to Packagist once you release it.
Set up the workflow like this:
Owner:
- In your GitHub repository, go to Settings > Actions > General and check the option "Allow GitHub Actions to create and approve pull requests".
Developer:
- In the root folder of your project, create a directory
.github/workflows/. This is where GitHub Action configuration files belong. - In this directory, create a new YAML file. Name it
release-and-publish.yml. - Copy the following code into your configuration file:
# This workflow opens and updates a pull request with a new package version
# based on code changes. Merging the pull request updates the version in
# composer.json, updates the changelog and creates release tags.
# This workflow also publishes the package into the Packagist repository after
# a new version has been released.
# https://github.com/marketplace/actions/release-please-action
on:
push:
branches:
- master
permissions:
contents: write
pull-requests: write
name: release-please
jobs:
release-please:
runs-on: ubuntu-22.04
steps:
- uses: google-github-actions/release-please-action@v3.7.10
with:
release-type: php
package-name: release-please-action
pull-request-title-pattern: "chore(release): ${version}"
pull-request-header: ":robot: Merge this PR to release a new version"
publish-package:
# after merging the pull request, a release tag first has to be created
# in the release-please job above, before the publish job starts
needs: release-please
if: contains(github.event.head_commit.message, 'chore(release)')
runs-on: ubuntu-22.04
steps:
- uses: actions/checkout@v3.5.3
- uses: hotaruma/packagist-sync@v1.0.1
with:
packagist-username: ${{ secrets.PACKAGIST_USERNAME }}
api-token: ${{ secrets.PACKAGIST_TOKEN }}
If your main branch is named something other than master (for example main), change it on Line 12. The publish-package job depends on the release-please job and must not start before it finishes successfully. The release job creates the version tag and the GitHub release, and the publish job needs that information to push the right version to Packagist.
-
Make sure your
composer.jsonincludes the version property (for example"version": "1.0.0"). release-please updates this property automatically every time you merge a version pull request, so the current SDK version is easy to read straight from the code. -
Commit these changes and push them to GitHub. The workflow is now set up. The next time someone adds something releasable with a conventional commit message (a
fix:orfeat:prefix), release-please opens a pull request. As you add more code, it updates the pull request automatically. When you are ready to ship a new version of your SDK, merge the pull request. The version is released and the updated SDK is published to Packagist.
release-please follows the Semantic Versioning (SemVer) specification, so it picks version numbers based on how significant your changes are. A breaking change bumps the major version, a new feature bumps the minor version, and a bug fix bumps the patch version. That makes it easy for your users to see how much each new version of your SDK changes.
For release-please to read the significance of your changes and pick the right version number, your commit messages need to follow the Conventional Commits format. Use a fixed prefix: "feat: add new feature" for a new feature, "fix: resolve bug" for a bug fix, "chore: update dependencies" for a non-code change. Stay consistent and release-please generates correct version numbers and changelogs. You can still edit the changelog by hand in the open pull request before you release.
Conclusion
You now have automated tools that release a new version of a PHP SDK and publish it to Packagist. With these steps in place, you free up time and budget that your team can spend on writing code instead.
If you need a hand with SDK development or automation, our team is ready to help. We can tighten your SDK development process, set up the automation, and save you time and money along the way.
Get in touch and let's talk about your SDK.
Need an automated release for another technology?
- Automated release for JavaScript
- Automated release for Ruby
- Explore our tool that automates all technologies at once
You might also be interested in:
Want to stay one step ahead?
Don't miss our best insights. No spam, just practical analyses, invitations to exclusive events, and podcast summaries delivered straight to your inbox.