{"id":13616804,"url":"https://github.com/laminas/automatic-releases","last_synced_at":"2026-02-17T23:03:08.497Z","repository":{"id":37590076,"uuid":"278461616","full_name":"laminas/automatic-releases","owner":"laminas","description":"Automated release process for `laminas/` projects, usable as github action","archived":false,"fork":false,"pushed_at":"2025-04-12T01:53:13.000Z","size":1868,"stargazers_count":142,"open_issues_count":38,"forks_count":22,"subscribers_count":14,"default_branch":"1.26.x","last_synced_at":"2025-04-12T02:51:37.515Z","etag":null,"topics":["automation","github-actions","laminas","release","tooling"],"latest_commit_sha":null,"homepage":"","language":"PHP","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/laminas.png","metadata":{"funding":{"community_bridge":"laminas-project"},"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-07-09T20:14:18.000Z","updated_at":"2025-04-07T05:46:32.000Z","dependencies_parsed_at":"2023-01-11T17:21:18.123Z","dependency_job_id":"c50acb53-d9b6-41d6-8cdd-7eb5ae1f0a27","html_url":"https://github.com/laminas/automatic-releases","commit_stats":{"total_commits":673,"total_committers":33,"mean_commits":"20.393939393939394","dds":0.7533432392273403,"last_synced_commit":"5b3d7e7a22e2ca58f32b047f701b91841910799f"},"previous_names":[],"tags_count":41,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/laminas%2Fautomatic-releases","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/laminas%2Fautomatic-releases/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/laminas%2Fautomatic-releases/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/laminas%2Fautomatic-releases/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/laminas","download_url":"https://codeload.github.com/laminas/automatic-releases/tar.gz/refs/heads/1.26.x","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248815563,"owners_count":21165947,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["automation","github-actions","laminas","release","tooling"],"created_at":"2024-08-01T20:01:33.482Z","updated_at":"2026-02-17T23:03:08.460Z","avatar_url":"https://github.com/laminas.png","language":"PHP","funding_links":["https://funding.communitybridge.org/projects/laminas-project"],"categories":["PHP"],"sub_categories":[],"readme":"# Release Automation\n\n[![Build Status](https://github.com/laminas/automatic-releases/workflows/Continuous%20Integration/badge.svg)](https://github.com/laminas/automatic-releases/actions?query=workflow%3A\"Continuous+Integration\")\n[![Psalm coverage](https://shepherd.dev/github/laminas/automatic-releases/coverage.svg?)](https://shepherd.dev/github/laminas/automatic-releases)\n\n\u003e ## 🇷🇺 Русским гражданам\n\u003e\n\u003e Мы, участники Laminas, родились и живем в разных странах. У многих из нас есть друзья, родственники и коллеги как в России, так и в Украине. Некоторые из нас родились в России. Некоторые из нас живут в России. У некоторых бабушки и дедушки сражались с фашистами во Второй мировой войне. Здесь никто не поддерживает фашизм.\n\u003e\n\u003e У одного из нас есть украинская родственница, которая спаслась из дома вместе с сыном. Поезд задержался из-за бомбежки на дороге впереди. У нас есть друзья, которые прячутся в бомбоубежищах. Мы с тревогой ждем весточки от них после воздушных налетов, которые беспорядочно наносят удары и попадают по больницам, школам, детским садам и домам. Мы не берем это из каких-либо СМИ. Мы наблюдаем это напрямую.\n\u003e\n\u003e Вы доверяете нам достаточно, чтоб использовать наши программы, и мы просим вас довериться нам вновь. Мы нуждаемся в помощи. Выходите и протестуйте против этой бесполезной войны. Остановите кровопролитие. Скажите \"Нет войне!\"\n\u003e\n\u003e ## 🇺🇸 To Citizens of Russia\n\u003e\n\u003e We at Laminas come from all over the world. Many of us have friends, family and colleagues in both Russia and Ukraine. Some of us were born in Russia. Some of us currently live in Russia. Some have grandparents who fought Nazis in World War II. Nobody here supports fascism.\n\u003e\n\u003e One team member has a Ukrainian relative who fled her home with her son. The train was delayed due to bombing on the road ahead. We have friends who are hiding in bomb shelters. We anxiously follow up on them after the air raids, which indiscriminately fire at hospitals, schools, kindergartens and houses. We're not taking this from any media. These are our actual experiences.\n\u003e\n\u003e You trust us enough to use our software. We ask that you trust us to say the truth on this. We need your help. Go out and protest this unnecessary war. Stop the bloodshed. Say \"stop the war!\"\n\nThis project is a [Github Action](https://github.com/features/actions) that allows\nmaintainers of open-source projects that follow [SemVer](https://semver.org/spec/v2.0.0.html)\nto automate the automation of releases.\n\n## Installation\n\nTo use this automation in your own repository, copy the [`examples/.github`](./examples/.github)\nworkflows into your own project:\n\n```sh\ncd /tmp\ngit clone https://github.com/laminas/automatic-releases.git\ncd /path/to/your/project\nmkdir -p .github/workflows\n# Copy selected flow that fits for your project\ncp /tmp/automatic-releases/examples/.github/release-on-milestone-closed.yml .github/workflows\n# ... or:\ncp /tmp/automatic-releases/examples/.github/release-on-milestone-closed-triggering-release-event.yml .github/workflows\ngit add .github/workflows\ngit commit -m \"Added release automation\"\n```\n\nTo get started you need to create a branch for the next release. e.g. if your next milestone will be\n`3.2.0` a `3.2.x` branch is required.\n\nThen add following [secrets](https://docs.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)\nto your project or organization:\n\n| Secret | Description |\n| ------ | ----------- |\n| `GIT_AUTHOR_NAME` | full name of the author of your releases: can be the name of a bot account. |\n| `GIT_AUTHOR_EMAIL` | email address of the author of your releases: can be an email address of a bot account. |\n| `SIGNING_SECRET_KEY` | a **password-less** private GPG key in ASCII format, to be used for signing your releases: please use a dedicated GPG subkey for this purpose. Unsigned releases are not supported, and won't be supported. See [Setting up GPG keys](#setting-up-gpg-keys) below for help. |\n| `ORGANIZATION_ADMIN_TOKEN` | You have to provide an `ORGANIZATION_ADMIN_TOKEN` (with a full repo scope), which is a github token with administrative rights over your organization (or regular user project, for non-organization projects), issued by a user that has administrative rights over your project (that's you, if it is your own non-organization repository). This is required for the `laminas:automatic-releases:switch-default-branch-to-next-minor` command, because [changing default branch of a repository currently requires administrative token rights](https://developer.github.com/v3/repos/#update-a-repository). You can generate a token from your [personal access tokens page](https://github.com/settings/tokens/new). |\n\nThe `GITHUB_TOKEN` secret you see in the examples is automatically created for\nyou when you enable GitHub Actions. To learn more about how it works, read\n[\"Authenticating with the GITHUB\\_TOKEN\"](https://docs.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)\nin the GitHub Docs.\n\n### Required Repository Settings\n\nWorkflow permissions for the target repository must be set to Read and Write.\nAdditionally, you must check the box to \"Allow GitHub Actions to create and approve pull requests\" in Settings \u003e Actions \u003e General.\nYou can find the settings in: `github.com/ORG-NAME/REPO-NAME/settings/actions`\n\n### Setting up GPG keys\n\n#### Using a subkey from an existing GPG key\n\nFirst open your master key for editing (use `--list-keys` to find it):\n\n```bash\ngpg --edit-key \"\u003cYOUR MASTER KEY ID\u003e\"\n```\n\nType `addkey` and select a type that is for signing, you might be asked about bit size depending on your choice.\nWhen deciding over key expire, avoid setting to never expire, as recommendation of key bits will change over time.\nType `save` to persist the new subkey to your master key. Make a note of the Key ID  as you will need it in the next step.\n\nNext export the new sub key:\n\n```bash\ngpg --output private.key --armor --export-secret-subkeys \"\u003cSubKey ID\u003e!\"\n```\n\nThis will be exported to the file `private.key`.\nThe `!` at the end is important as it limits the export to just the sub key\n\n**Delete the file once you are done** and don't share it with anyone else\n\nIf your master key is password protected, you will need to remove the password from the subkey before you can add it into github settings.\nYou can skip this if your master key is not password protected.\n\nTo remove the password from the subkey, create an ephemeral gpg home directory:\n\n```bash\ninstall -d -m 700 gpg-tmp\n```\n\nEnsure that it works with gpg:\n\n```bash\ngpg --homedir gpg-tmp --list-keys\n```\n\nImport your subkey:\n\n```bash\ngpg --homedir gpg-tmp --import private.key\n```\n\nEnter edit mode:\n\n```bash\ngpg --homedir gpg-tmp --edit-key \u003cSubKey ID\u003e\n```\n\nType `passwd`, entering your current password and then set the password to \"\" to remove it.\n\nThe command may give error `error changing passphrase: No secret key` when setting empty password.\nYou should ignore it as the password was really removed.\n\nType `save` to exit edit mode and re-export your subkey:\n\n```bash\ngpg --homedir gpg-tmp --output private.key --armor --export-secret-subkeys \"\u003cSubKey ID\u003e!\"\n```\n\nFinally, remove the ephemeral directory:\n\n```bash\nrm -rf gpg-tmp\n```\n\nYou will now need to export your master public key with the new subkey public key to the file `public.key`:\n\n```bash\ngpg --output public.key --armor --export \u003cYOUR MASTER KEY ID\u003e\n```\n\nThen republish it to anywhere that you currently publish your public keys.\n\n#### Using a new key\n\nTo generate a new GPG key use the following command:\n\n```bash\ngpg2 --full-generate-key\n```\n\nPick option 4, then type `4096` for key size, select your desired expiry.\nFill out the user information and leave the password blank.\n\nOnce generated it will output something like `gpg: key \u003cKey ID\u003e marked as ultimately trusted`. Take a note of this Key Id to use in the next step.\n\nNow output the key to the file `private.key` in the correct format to put into the environment variable required for setup:\n\n```bash\ngpg --output private.key --armor --export-secret-key \u003cKey ID\u003e\n```\n\n**Delete the file once you are done** and don't share it with anyone else\n\nOptionally, you can export the corresponding public key to the file `public.key`:\n\n```bash\ngpg --output public.key --armor --export \u003cKey ID\u003e\n```\n\nYou can publish this key on your project webpage to allow users to verify your signed releases.\nYou could sign this new key with your personal key and the keys of other project maintainers to establish its provenance.\n\n## Usage\n\nAssuming your project has Github Actions enabled, each time you [**close**](https://developer.github.com/webhooks/event-payloads/#milestone)\na [**milestone**](https://docs.github.com/en/github/managing-your-work-on-github/creating-and-editing-milestones-for-issues-and-pull-requests),\nthis action will perform all following steps (or stop with an error):\n\n1. determine if all issues and pull requests associated with this milestone are closed\n2. determine if the milestone is named with the SemVer `x.y.z` format\n3. create a changelog by looking at the milestone description and associated issues and pull requests\n4. select branch `x.y.z` for the release (e.g. `1.1.x` for a `1.1.0` release)\n5. create a tag named `x.y.z` on the selected branch, with the generated changelog\n6. publish a release named `x.y.z`, with the generated tag and changelog\n7. create (if applicable), a pull request from the selected branch to the next release branch\n8. create (if necessary) a \"next minor\" release branch `x.y+1.z`\n9. switch default repository branch to newest release branch\n\nPlease read the [`feature/`](./feature) specification for more detailed scenarios on how the tool is supposed\nto operate.\n\n## Branching model\n\nIn this model we operate with release branches (e.g. `1.0.x`, `1.1.x`, `1.2.x`).\nThis provides a lot of flexibility whilst keeping a single workflow.\n\n![Branching model visualisation](./docs/branching-model.svg)\n\n### Working on new features\n\nThe current default release branch should be used. The default branch is always automatically changed\nafter a new release is created.\n\nAn example is Mezzio that has `3.2.x` as the current default release branch for simple features and\ndeprecation notices and `4.0.x` for the next major release.\n\n### Working on bug fixes\n\nBug fixes should be applied on the version which introduced the issue and then synchronized all way to\nthe current default release branch via merge-ups.\n\n### Releasing\n\nWhen releasing a new version `x.y.z`, a new branch will be created `x.y+1.z` and will be set as the next\ndefault release branch. If a hotfix `x.y.z+1` is released, a merge-up branch is automatically created.\n\n### Synchronizing branches\n\nTo keep branches synchronized merge-ups are used.\n\nThat consists in getting the changes of a specific released branch merged all the way up to the current\ndefault branch. This ensures that all release branches are up-to-date and will never present a bug which\nhas already been fixed. Merge-up branches are automatically created but needs to be merged manually into\nthe targeted branch.\n\n#### Example\n\nLet's say we've released the versions `1.0.0` and `1.1.0`.\nNew features are being developed on `1.2.x`.\nAfter a couple weeks, a bug was found on version `1.0.0`.\n\nThe fix for that bug should be done based on the branch `1.0.x` and, once merged, the branches should be updated\nin this way:\n\n1. Create a PR for the automatically created branch `1.0.x-merge-up-into-1.1.x_*`, using `1.1.x` as destination.\n1. Merge the new PR into `1.1.x`.\n1. Create a PR for the automatically created branch `1.1.x-merge-up-into-1.2.x_*`, using `1.2.x` as destination.\n1. Merge the new PR into `1.2.x`.\n\n:warning: when the merge-up can't be merged due to conflicts, it needs to be synced with the destination branch.\nThat's done by merging the destination into the merge-up branch and resolving the conflicts locally:\n\n1. Update your local repository (`git fetch origin`)\n1. Checkout to merge-up branch (`git checkout 1.1.x-merge-up-into-1.2.x_*`)\n1. Sync merge-up branch (`git merge --no-ff origin/1.2.x`)\n1. Solve conflicts (using `git mergetool` or through an IDE)\n1. Resume merge (`git merge --continue`)\n1. Push (`git push`)\n\nIf needed you can create a merge-up branch manually: `git checkout 1.0.x \u0026\u0026 git checkout -b 1.0.x-merge-up-into-1.1.x`\n\n## Triggering release workflow events\n\nBecause the tokens generated by GitHub Actions are considered OAuth tokens,\nthey are incapable of triggering further workflow events ([see this document for\nan explanation](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#triggering-new-workflows-using-a-personal-access-token)).\n\nAs such, if you want to trigger a release event when automatic-releases runs,\nyou will need to modify your `.github/workflows/release-on-milestone-closed.yml`\nfile to assign the `ORGANIZATION_ADMIN_TOKEN` as the value of the\n`GITHUB_TOKEN` environment variable for the `Release` step:\n\n```yaml\n    - name: \"Release\"\n      uses: \"./\"\n      with:\n        command-name: \"laminas:automatic-releases:release\"\n      env:\n        \"GITHUB_TOKEN\": ${{ secrets.ORGANIZATION_ADMIN_TOKEN }}\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flaminas%2Fautomatic-releases","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flaminas%2Fautomatic-releases","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flaminas%2Fautomatic-releases/lists"}