laminas / automatic-releases

Automated release process for `laminas/` projects, usable as github action

Release Automation

🇷🇺 Русским гражданам

Мы, участники Laminas, родились и живем в разных странах. У многих из нас есть друзья, родственники и коллеги как в России, так и в Украине. Некоторые из нас родились в России. Некоторые из нас живут в России. У некоторых бабушки и дедушки сражались с фашистами во Второй мировой войне. Здесь никто не поддерживает фашизм.

У одного из нас есть украинская родственница, которая спаслась из дома вместе с сыном. Поезд задержался из-за бомбежки на дороге впереди. У нас есть друзья, которые прячутся в бомбоубежищах. Мы с тревогой ждем весточки от них после воздушных налетов, которые беспорядочно наносят удары и попадают по больницам, школам, детским садам и домам. Мы не берем это из каких-либо СМИ. Мы наблюдаем это напрямую.

Вы доверяете нам достаточно, чтоб использовать наши программы, и мы просим вас довериться нам вновь. Мы нуждаемся в помощи. Выходите и протестуйте против этой бесполезной войны. Остановите кровопролитие. Скажите "Нет войне!"

🇺🇸 To Citizens of Russia

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.

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.

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!"

This project is a Github Action that allows maintainers of open-source projects that follow SemVer to automate the automation of releases.

Installation

To use this automation in your own repository, copy the examples/.github workflows into your own project:

cd /tmp
git clone https://github.com/laminas/automatic-releases.git
cd /path/to/your/project
mkdir -p .github/workflows
# Copy selected flow that fits for your project
cp /tmp/automatic-releases/examples/.github/release-on-milestone-closed.yml .github/workflows
# ... or:
cp /tmp/automatic-releases/examples/.github/release-on-milestone-closed-triggering-release-event.yml .github/workflows
git add .github/workflows
git commit -m "Added release automation"

To get started you need to create a branch for the next release. e.g. if your next milestone will be 3.2.0 a 3.2.x branch is required.

Then add following secrets to your project or organization:

Secret	Description
GIT_AUTHOR_NAME	full name of the author of your releases: can be the name of a bot account.
GIT_AUTHOR_EMAIL	email address of the author of your releases: can be an email address of a bot account.
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 below for help.
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. You can generate a token from your personal access tokens page.

The GITHUB_TOKEN secret you see in the examples is automatically created for you when you enable GitHub Actions. To learn more about how it works, read "Authenticating with the GITHUB_TOKEN" in the GitHub Docs.

Setting up GPG keys

Using a subkey from an existing GPG key

First open your master key for editing (use --list-keys to find it):

gpg --edit-key "<YOUR MASTER KEY ID>"

Type addkey and select a type that is for signing, you might be asked about bit size depending on your choice. When deciding over key expire, avoid setting to never expire, as recommendation of key bits will change over time. Type 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.

Next export the new sub key:

gpg --output private.key --armor --export-secret-subkeys "<SubKey ID>!"

This will be exported to the file private.key. The ! at the end is important as it limits the export to just the sub key

Delete the file once you are done and don't share it with anyone else

If your master key is password protected, you will need to remove the password from the subkey before you can add it into github settings. You can skip this if your master key is not password protected.

To remove the password from the subkey, create an ephemeral gpg home directory:

install -d -m 700 gpg-tmp

Ensure that it works with gpg:

gpg --homedir gpg-tmp --list-keys

Import your subkey:

gpg --homedir gpg-tmp --import private.key

Enter edit mode:

gpg --homedir gpg-tmp --edit-key <SubKey ID>

Type passwd, entering your current password and then set the password to "" to remove it.

The command may give error error changing passphrase: No secret key when setting empty password. You should ignore it as the password was really removed.

Type save to exit edit mode and re-export your subkey:

gpg --homedir gpg-tmp --output private.key --armor --export-secret-subkeys "<SubKey ID>!"

Finally, remove the ephemeral directory:

rm -rf gpg-tmp

You will now need to export your master public key with the new subkey public key to the file public.key:

gpg --output public.key --armor --export <YOUR MASTER KEY ID>

Then republish it to anywhere that you currently publish your public keys.

Using a new key

To generate a new GPG key use the following command:

gpg2 --full-generate-key

Pick option 4, then type 4096 for key size, select your desired expiry. Fill out the user information and leave the password blank.

Once generated it will output something like gpg: key <Key ID> marked as ultimately trusted. Take a note of this Key Id to use in the next step.

Now output the key to the file private.key in the correct format to put into the environment variable required for setup:

gpg --output private.key --armor --export-secret-key <Key ID>

Delete the file once you are done and don't share it with anyone else

Optionally, you can export the corresponding public key to the file public.key:

gpg --output public.key --armor --export <Key ID>

You can publish this key on your project webpage to allow users to verify your signed releases. You could sign this new key with your personal key and the keys of other project maintainers to establish its provenance.

Usage

Assuming your project has Github Actions enabled, each time you close a milestone, this action will perform all following steps (or stop with an error):

1. determine if all issues and pull requests associated with this milestone are closed
2. determine if the milestone is named with the SemVer x.y.z format
3. create a changelog by looking at the milestone description and associated issues and pull requests
4. select branch x.y.z for the release (e.g. 1.1.x for a 1.1.0 release)
5. create a tag named x.y.z on the selected branch, with the generated changelog
6. publish a release named x.y.z, with the generated tag and changelog
7. create (if applicable), a pull request from the selected branch to the next release branch
8. create (if necessary) a "next minor" release branch x.y+1.z
9. switch default repository branch to newest release branch

Please read the feature/ specification for more detailed scenarios on how the tool is supposed to operate.

Branching model

In this model we operate with release branches (e.g. 1.0.x, 1.1.x, 1.2.x). This provides a lot of flexibility whilst keeping a single workflow.

Working on new features

The current default release branch should be used. The default branch is always automatically changed after a new release is created.

An example is Mezzio that has 3.2.x as the current default release branch for simple features and deprecation notices and 4.0.x for the next major release.

Working on bug fixes

Bug fixes should be applied on the version which introduced the issue and then synchronized all way to the current default release branch via merge-ups.

Releasing

When releasing a new version x.y.z, a new branch will be created x.y+1.z and will be set as the next default release branch. If a hotfix x.y.z+1 is released, a merge-up branch is automatically created.

Synchronizing branches

To keep branches synchronized merge-ups are used.

That consists in getting the changes of a specific released branch merged all the way up to the current default branch. This ensures that all release branches are up-to-date and will never present a bug which has already been fixed. Merge-up branches are automatically created but needs to be merged manually into the targeted branch.

Example

Let's say we've released the versions 1.0.0 and 1.1.0. New features are being developed on 1.2.x. After a couple weeks, a bug was found on version 1.0.0.

The fix for that bug should be done based on the branch 1.0.x and, once merged, the branches should be updated in this way:

1. Create a PR for the automatically created branch 1.0.x-merge-up-into-1.1.x_*, using 1.1.x as destination.
2. Merge the new PR into 1.1.x.
3. Create a PR for the automatically created branch 1.1.x-merge-up-into-1.2.x_*, using 1.2.x as destination.
4. Merge the new PR into 1.2.x.

⚠️ when the merge-up can't be merged due to conflicts, it needs to be synced with the destination branch. That's done by merging the destination into the merge-up branch and resolving the conflicts locally:

1. Update your local repository (git fetch origin)
2. Checkout to merge-up branch (git checkout 1.1.x-merge-up-into-1.2.x_*)
3. Sync merge-up branch (git merge --no-ff origin/1.2.x)
4. Solve conflicts (using git mergetool or through an IDE)
5. Resume merge (git merge --continue)
6. Push (git push)

If needed you can create a merge-up branch manually: git checkout 1.0.x && git checkout -b 1.0.x-merge-up-into-1.1.x

Triggering release workflow events

Because the tokens generated by GitHub Actions are considered OAuth tokens, they are incapable of triggering further workflow events (see this document for an explanation).

As such, if you want to trigger a release event when automatic-releases runs, you will need to modify your .github/workflows/release-on-milestone-closed.yml file to assign the ORGANIZATION_ADMIN_TOKEN as the value of the GITHUB_TOKEN environment variable for the Release step:

    - name: "Release"
      uses: "./"
      with:
        command-name: "laminas:automatic-releases:release"
      env:
        "GITHUB_TOKEN": ${{ secrets.ORGANIZATION_ADMIN_TOKEN }}

automatic-releases's Issues

`CreateMilestones` command is not covered by any tests

Q	A
Version(s)	1.12.0

Summary

This code does not seem to be touched/verified by any existing tests:

automatic-releases/src/Application/Command/CreateMilestones.php

Lines 16 to 52 in da94ae9

	final class CreateMilestones extends Command
	{
	private LoadCurrentGithubEvent $loadEvent;
	private CreateMilestone $createMilestone;
	public function __construct(
	LoadCurrentGithubEvent $loadEvent,
	CreateMilestone $createMilestone
	) {
	parent::__construct('laminas:automatic-releases:create-milestones');
	$this->loadEvent = $loadEvent;
	$this->createMilestone = $createMilestone;
	}
	public function execute(InputInterface $input, OutputInterface $output): int
	{
	$milestoneClosedEvent = ($this->loadEvent)();
	$repositoryName = $milestoneClosedEvent->repository();
	$releaseVersion = $milestoneClosedEvent->version();
	$this->createMilestoneIfNotExists($repositoryName, $releaseVersion->nextPatch());
	$this->createMilestoneIfNotExists($repositoryName, $releaseVersion->nextMinor());
	$this->createMilestoneIfNotExists($repositoryName, $releaseVersion->nextMajor());
	return 0;
	}
	private function createMilestoneIfNotExists(RepositoryName $repositoryName, SemVerVersion $version): void
	{
	try {
	($this->createMilestone)($repositoryName, $version);
	} catch (CreateMilestoneFailed) {
	return;
	}
	}
	}

Whenever a `CHANGELOG.md` release date is set, also create a new "next release" block with the `TBD` in the date

Feature Request

Requires #18

Discussed with @weierophinney: we probably want to prepare the next CHANGELOG.md block each time we do a release, so maintainers don't have to manually add the CHANGELOG.md template:

## $x.$y+1.0 - TBD

- Nothing.

### Added

- Even moar stuff by @ocramius, but nobody really cares :D 

### Changed

- Nothing.

### Deprecated

- Nothing.

### Removed

- Nothing.

### Fixed

- Nothing.

Not sure if we should generate the block for $x.$y+1.0, or also for $x.$y.$z+1 🤔

Q	A
New Feature	yes
RFC	no
BC Break	yes

Major version tag `v1` for action reference

Feature Request

Q	A
New Feature	sort of

Summary

As a user I want to use the latest stable action without having to update my github action scripts all the time. GitHub suggest to create a v1 tag that will follow the latest 1.x release.

e.g. the current example script still points to laminas/[email protected] while 1.1.0 is out.

By using v1 tags which follow the latest stable release, you can use something like this, laminas/automatic-releases@v1.

https://docs.github.com/en/actions/creating-actions/about-actions#using-tags-for-release-management

I think this is also useful for all laminas and mezzio packages. As we manually "move" the v1 tag, we can decide when we are happy with a specific stable release and move the v1 tag so all components will start using it.

Add descriptions to automatically created milestones

Feature Request

Q	A
New Feature	yes

Summary

Add descriptions to automatically created milestones to clarify what they are for.

# 2.12.4
next 2.12.x bug fix release (patch)

# 2.13.0
next feature release (minor)

# 3.0.0
next backward compatibility break release (major)

Automatically delete unmaintained branches?

Feature Request

Q	A
New Feature	yes
RFC	yes
BC Break	no

Summary

The Laminas organization has a relatively straightforward support policy of not supporting any version that depends on a PHP release that is EOL'd:

• https://www.php.net/supported-versions.php
• https://github.com/laminas/technical-steering-committee/blob/c7f6babfb1773d9cb9371208102cbb8b27980bd5/meetings/minutes/2020-03-02-TSC-Minutes.md#lts-policy

This means that, based on supported-versions.php (or similar database), we can automatically delete branches with X.Y.x naming, and all their associated open milestones, when the PHP version goes EOL.

Since this is laminas-specific, and not really pertinent to release automation per-se, it may be a concern for a different tool, or a specific action within this tool.

Expected a value to be true. Got: false

Bug Report

Q	A
Version(s)	1.8.0

Summary

laminas:automatic-releases:release crashes without a stack trace, just the unhelpful error message in the title

Current behavior

• crash as seen at https://github.com/doctrine/orm/runs/1236034190?check_suite_focus=true#step:4:14
• no stack trace

How to reproduce

Running the action on doctrine/orm 2.7 should work

Expected behavior

No crash, or at least, a crash with a stack trace (use -vvv?)

Move all open issues from closed milestone to next mini release

Feature Request

Q	A
New Feature	yes
RFC	yes/no
BC Break	yes/no

Summary

Instead of failing with an assertion that there are still open issues on the milestone, the release tool could move all issues to the next milestone.

Bump `milestone` in `.github/dependabot.yml`, when available?

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	no

laminas/automatic-releases works exceptionally well with milestone automation, but dependabot updates often don't land in milestone/release notes, due to dependabot not assigning a milestone to opened PRs.

This could be automated, by assigning a milestone number/name (both seem to be supported) when creating a new milestone: https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#milestone

Unsure if this is to be pursued, as it may lead to git conflicts (unlikely, because dependabot only acts on latest branches), but it could be an interesting idea to do so.

In practice, when a new milestone is created, we push a new commit with the milestone: value to each dependabot.yml#updates[].milestone entry (or set it, if not existing).

Known limitation: can only handle the first 100 issues/PRs in a release

Bug Report

Q	A
Version(s)	1.0.0

Summary

This is a known limitation currently.

Randomly not creating next release branch

Bug Report

Q	A
Version(s)	v1 (1.9.0?)

Summary

After performing the 2.9.0 release on laminas-paginator, a new release branch was not created (expected 2.10.x creation).

I'm unsure how to reproduce. What may be more useful in addressing this is to add logging wherever we can (particularly since we have a logger available now).

Make error of token with less privileges more human readable

Feature Request

Q	A
New Feature	yes
RFC	yes/no
BC Break	yes/no

Summary

The job at https://github.com/perftools/xhgui/runs/1768245086?check_suite_focus=true failed with Expected a value less than or equal to 299. Got: 403

Run laminas/automatic-releases@v1
/usr/bin/docker run --name b701c1ddc6e94b279ef6bde6662762df_a08c92 --label 442333 --workdir /github/workspace --rm -e GITHUB_TOKEN -e SIGNING_SECRET_KEY -e GIT_AUTHOR_NAME -e GIT_AUTHOR_EMAIL -e INPUT_COMMAND-NAME -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/xhgui/xhgui":"/github/workspace" 442333:b701c1ddc6e94b279ef6bde6662762df  "laminas:automatic-releases:switch-default-branch-to-next-minor"
[2021-01-26T09:49:52.356516+00:00] automatic-releases.INFO: BumpAndCommitChangelogVersion: No CHANGELOG.md file detected [] []

In Assert.php line 2042:
                                                        
  Expected a value less than or equal to 299. Got: 403  
                                                        

laminas:automatic-releases:switch-default-branch-to-next-minor

It's better to say "Failed to create Milestone, the given token does not have enough privileges".

The error happened because the job was set up to run with GITHUB_TOKEN, but that has not enough privileges:

• #105

Increase `STDERR` verbosity of CLI commands

While the commands are tested, we still cannot consider this "battle tested": we need to add more STDERR output to see what each command is doing, and when.

This is effectively just to aid downstream consumers in identifying any issues encountered during action execution.

Automatically change branch name in README.md when creating new version branch

Feature Request

Q	A
New Feature	yes

Summary

Hey there,

in most laminas projects are badges for coveralls and travis build results. These badges point on builds for specific branches on travis/coveralls.

When laminas/automatic-releases kicks in, the branch is still pointing to the initial branch (which was probably set up when the package was created).

I'd like this tool to change the branch name in the README.md aswell so travis builds and coveralls stats are shown for the branch one is working on.

Display command output on failure

Feature Request

Q	A
New Feature	yes
RFC	yes
BC Break	no

Summary

Right now, potentially helpful output of external programs is not displayed on error, making it hard to troubleshoot them: https://github.com/doctrine/orm/runs/3782157355?check_suite_focus=true#step:4:18

I can think of 2 solutions:

• catch the exception, and wrap it with another that includes the result of $e->getOutput() and $e->getErrorOutput()
• file an issue on azjezz/psl so that the output is included in the exception's error message.

Cc @azjezz

Add branching model description (and assumptions) to the repository description

We probably could introduce the branching model by @lcobucci in https://gist.github.com/lcobucci/ebb450bc3f7b93b3dc1a1a62e0df2186

That needs to be polished a bit (mostly proof-reading) and included in this repo README.md

Add mechanism to automatically switch active branch on a new minor or major release

As discussed in the @laminas/technical-steering-committee meeting, we want to move away from the master branch naming, towards a more user-friendly naming scheme that exposes version names.

The idea is that whenever a x.y.0 or x.0.0 release is tagged, the tool will automatically switch to that release's branch, if it is the latest.

New minor

For example, given following branches:

• 1.0.x
• 1.1.x marked as default

When 1.2.0 is tagged, we should see:

• 1.0.x
• 1.1.x
• 1.2.x marked as default

New major

For example, given following branches:

• 1.0.x
• 1.1.x
• 1.2.x marked as default

When 2.0.0 is tagged, we should see:

• 1.0.x
• 1.1.x
• 1.2.x
• 2.0.x marked as default

Commit changelog after updating with release date fails, indicating wrong branch is checked out

Bug Report

Q	A
Version(s)	1.2.2

Summary

When issuing a release for laminas-mail, I received an error indicating it could not commit the changelog file back to the release branch, as that branch was not currently selected:

• https://github.com/laminas/laminas-mail/runs/977187215?check_suite_focus=true#step:4:14

How to reproduce

Close a milestone, and wait for the action to complete.

Expected behavior

If the action is able to read and manipulate the changelog file, it should be able to commit it back to the repo.

Add branch protection to release branches

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	no

Summary

Hi, I'd love to have branch protection (here's the API) automatically added for release branches created by this action.

There are many options and we could provide a 1:1 config-to-API environment variables, but we could start with a basic on/off one for the destruction-protective ones:

{
  "allow_force_pushes": false,
  "allow_deletions": false
}

Set up `ORGANIZATION_ADMIN_TOKEN` to allow for automatic branch switching

Self-release partially succeeded, but we had a failure later in actions run:

 /usr/bin/docker run --name c20181c155a4ed455de0bcfd869a25c9bb5f_021211 --label 87c201 --workdir /github/workspace --rm -e GITHUB_TOKEN -e SIGNING_SECRET_KEY -e GIT_AUTHOR_NAME -e GIT_AUTHOR_EMAIL -e INPUT_COMMAND-NAME -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/automatic-releases/automatic-releases":"/github/workspace" 87c201:81c155a4ed455de0bcfd869a25c9bb5f  "laminas:automatic-releases:switch-default-branch-to-next-minor"

Caused

Fatal error: Uncaught InvalidArgumentException: Could not find a value for environment variable "GITHUB_TOKEN" in /app/vendor/webmozart/assert/src/Assert.php:2042
Stack trace:
#0 /app/vendor/webmozart/assert/src/Assert.php(779): Webmozart\Assert\Assert::reportInvalidArgument('Could not find ...')
#1 /app/vendor/webmozart/assert/src/Assert.php(69): Webmozart\Assert\Assert::notEq('', '', 'Could not find ...')
#2 /app/src/Environment/EnvironmentVariables.php(72): Webmozart\Assert\Assert::stringNotEmpty('', 'Could not find ...')
#3 /app/src/Environment/EnvironmentVariables.php(55): Laminas\AutomaticReleases\Environment\EnvironmentVariables::getenv('GITHUB_TOKEN')
#4 /app/bin/console.php(47): Laminas\AutomaticReleases\Environment\EnvironmentVariables::fromEnvironment(Object(Laminas\AutomaticReleases\Gpg\ImportGpgKeyFromStringViaTemporaryFile))
#5 /app/bin/console.php(113): Laminas\AutomaticReleases\WebApplication\{closure}()
#6 {main}
  thrown in /app/vendor/webmozart/assert/src/Assert.php on line 2042

That's because ORGANIZATION_ADMIN_TOKEN is not set.

It's obviously a bit risky to add such a variable to the environment, but it should be fine if it's marked as protected (only direct pushes to repository branches can access it).

#8 restore `laminas/automatic-releases` CLI application version parsing

In #8 and #10, we disable version parsing by removing .git from the Dockerfile: we will need to re-enable it again, so that the correct application version can be rendered in case of bugs:

automatic-releases/bin/console.php

Line 68 in ea00621

$application = new Application(Versions::ROOT_PACKAGE_NAME, Versions::getVersion('laminas/automatic-releases'));

Add linebreak at end of changelog entries inserted into CHANGELOG.md files

Bug Report

Q	A
Version(s)	1.5.0

Summary

We need an extra line break following changelog contents for a version.

Current behavior

Currently, when rewriting contents for a CHANGELOG.md version entry, the last line of contents is immediately followed by the heading for the next version. It needs a line break between.

Better error handling

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	no

Summary

The GitHub API returns a response like {"message":"error message", "errors": ['error 1','error 2']} on error. We should utilise this field if available, falling back to the current generic error messages.

Release fails due to `azjezz/psl` coercion error

Bug Report

Q	A
Version(s)	1.12.2

Summary

I've encountered an issue when releasing for the first time. In another project, that worked as of yesterday but today its broken in another project...

Current behavior

/usr/bin/docker run --name ghcriolaminasautomaticreleases1_742f3c --label 3bec5f --workdir /github/workspace --rm -e GITHUB_TOKEN -e SIGNING_SECRET_KEY -e GIT_AUTHOR_NAME -e GIT_AUTHOR_EMAIL -e INPUT_COMMAND-NAME -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/laminas-cache-storage-adapter-benchmark/laminas-cache-storage-adapter-benchmark":"/github/workspace" ghcr.io/laminas/automatic-releases:1  "laminas:automatic-releases:release"
[2021-08-08T11:38:30.784862+00:00] automatic-releases.INFO: CommitReleaseChangelog: no changes to commit. [] []

In typed.php line 25:
                                                                           
  [Psl\Json\Exception\DecodeException]                                     
  Could not coerce "array" to type "array{'html_url': non-empty-string}".  
                                                                           

Exception trace:
  at /app/vendor/azjezz/psl/src/Psl/Json/typed.php:25
 Psl\Json\typed() at /app/src/Github/Api/V3/CreateReleaseThroughApiCall.php:70
 Laminas\AutomaticReleases\Github\Api\V3\CreateReleaseThroughApiCall->__invoke() at /app/src/Application/Command/ReleaseCommand.php:112
 Laminas\AutomaticReleases\Application\Command\ReleaseCommand->execute() at /app/vendor/symfony/console/Command/Command.php:256
 Symfony\Component\Console\Command\Command->run() at /app/vendor/symfony/console/Application.php:971
 Symfony\Component\Console\Application->doRunCommand() at /app/vendor/symfony/console/Application.php:290
 Symfony\Component\Console\Application->doRun() at /app/vendor/symfony/console/Application.php:166
 Symfony\Component\Console\Application->run() at /app/bin/console.php:171
 Laminas\AutomaticReleases\WebApplication\{closure}() at /app/bin/console.php:172

In CoercionException.php line 34:
                                                                           
  [Psl\Type\Exception\CoercionException]                                   
  Could not coerce "array" to type "array{'html_url': non-empty-string}".  
                                                                           

Exception trace:
  at /app/vendor/azjezz/psl/src/Psl/Type/Exception/CoercionException.php:34
 Psl\Type\Exception\CoercionException::withValue() at /app/vendor/azjezz/psl/src/Psl/Type/Internal/ShapeType.php:63
 Psl\Type\Internal\ShapeType->coerce() at /app/vendor/azjezz/psl/src/Psl/Json/typed.php:23
 Psl\Json\typed() at /app/src/Github/Api/V3/CreateReleaseThroughApiCall.php:70
 Laminas\AutomaticReleases\Github\Api\V3\CreateReleaseThroughApiCall->__invoke() at /app/src/Application/Command/ReleaseCommand.php:112
 Laminas\AutomaticReleases\Application\Command\ReleaseCommand->execute() at /app/vendor/symfony/console/Command/Command.php:256
 Symfony\Component\Console\Command\Command->run() at /app/vendor/symfony/console/Application.php:971
 Symfony\Component\Console\Application->doRunCommand() at /app/vendor/symfony/console/Application.php:290
 Symfony\Component\Console\Application->doRun() at /app/vendor/symfony/console/Application.php:166
 Symfony\Component\Console\Application->run() at /app/bin/console.php:171
 Laminas\AutomaticReleases\WebApplication\{closure}() at /app/bin/console.php:172

laminas:automatic-releases:release

https://github.com/laminas/laminas-cache-storage-adapter-benchmark/runs/3273400689?check_suite_focus=true

After this issue occured, re-opening a milestone and closing it again to trigger another release will lead to:

/usr/bin/docker run --name ghcriolaminasautomaticreleases1_cd45f4 --label 3bec5f --workdir /github/workspace --rm -e GITHUB_TOKEN -e SIGNING_SECRET_KEY -e GIT_AUTHOR_NAME -e GIT_AUTHOR_EMAIL -e INPUT_COMMAND-NAME -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/laminas-cache-storage-adapter-benchmark/laminas-cache-storage-adapter-benchmark":"/github/workspace" ghcr.io/laminas/automatic-releases:1  "laminas:automatic-releases:release"
[2021-08-08T11:40:27.039270+00:00] automatic-releases.INFO: CommitReleaseChangelog: no changes to commit. [] []

In execute.php line 82:
                                                                               
  [Psl\Shell\Exception\FailedExecutionException (128)]                         
  Shell command "git 'tag' '1.0.0' '-F' '/tmp/created_tagc1lpumEb' '--cleanup  
  =whitespace' '--local-user=10B7743EC1CCD759'" returned an exit code of "128  
  ".                                                                           
                                                                               

Exception trace:
  at /app/vendor/azjezz/psl/src/Psl/Shell/execute.php:82
 Psl\Shell\execute() at /app/src/Git/CreateTagViaConsole.php:27
 Laminas\AutomaticReleases\Git\CreateTagViaConsole->__invoke() at /app/src/Application/Command/ReleaseCommand.php:108
 Laminas\AutomaticReleases\Application\Command\ReleaseCommand->execute() at /app/vendor/symfony/console/Command/Command.php:256
 Symfony\Component\Console\Command\Command->run() at /app/vendor/symfony/console/Application.php:971
 Symfony\Component\Console\Application->doRunCommand() at /app/vendor/symfony/console/Application.php:290
 Symfony\Component\Console\Application->doRun() at /app/vendor/symfony/console/Application.php:166
 Symfony\Component\Console\Application->run() at /app/bin/console.php:171
 Laminas\AutomaticReleases\WebApplication\{closure}() at /app/bin/console.php:172

laminas:automatic-releases:release

https://github.com/laminas/laminas-cache-storage-adapter-benchmark/runs/3273405991?check_suite_focus=true

The second error occurs due to the fact that the tag creation worked - just the release artifact creation didn't worked.

How to reproduce

TBH, I don't really know. The actual response of the github API is not passed to the error so I don't really know whats going on.

automatic-releases/src/Github/Api/V3/CreateReleaseThroughApiCall.php

Line 70 in c7260cc

'html_url' => Type\non_empty_string(),

Expected behavior

Release works as expected and if an error occurs, re-opening and re-closing a milestone should not run into the same error over and over again due to the fact that the tag already exists.

[RFC]: Support optional <major>.x as branch name for upcoming releases

RFC

Q	A
Proposed Version(s)	x.y.0
BC Break?	Not sure

Goal

Consider branch names of the form <major>.x as source for releases when tagging <major>.<minor>.0 releases.

Background

Currently, the tool requires a branch name in the form <major>.<minor>.x to be present to create a new release. If this branch does not exist, the tool halts with an error. Furthermore, the tool makes this branch the new default branch in the repository unless a newer release branch (<major+1>.*.x or <major>.<minor+1>.x) exists.

This last part can be an issue, as it requires re-targeting pull requests to the new default branch, which can be cumbersome. Thus, I propose adding support for development branches that follow the <major>.x syntax. This branch can be considered a development branch for the upcoming minor version of the indicated major release series.

The behaviour of the tool when closing a <major>.<minor>.0 milestone would change as follows:

• If a <major>.<minor>.x branch already exists, the tool works the same way it does now.
• If the above branch does not exist, but a <major>.x branch exists, the tool creates and pushes a <major>.<minor>.x branch created from <major>.x, then proceeds as if the branch existed beforehand.
• If neither <major>.<minor>.x branch nor <major>.x branch exists, the tool halts with an error as it does now.

When updating default branches, the tool should consider <major>.x branches as well. Instead of choosing the latest <major>.<minor>.x branch, the following rules apply:

• a <major>.x branch always takes precedence over <major>.<minor>.x
• a <major>.x branch never takes precedence over <major+1>.<minor>.x
• no change is necessary in situation where the release tool currently decides not to update the default branch.

Considerations

I don't expect any negative impact on users due to this change, but a toggle to enable this behaviour can be considered to require users to opt-in to this new behaviour.

Proposal(s)

I can create a PR for the change, but wanted to check with the maintainers before investing the time to do so.

Appendix

If the proposal above is accepted, another approach would be to define a general fallback name as release source for when the release branch does not exist. However, that is not part of this proposal as there are more cases to consider.

Fix release markdown rendering of double newlines

Bug Report

Q	A
Version(s)	v1

Summary

Because there's a double newline between two lists, markdown renders every item with double newlines and considers the two lists as one.

The workaround is to put some non-list element between the lists.

Current behavior

markdown source

### Release Notes for [0.19.1](https://github.com/perftools/xhgui/milestone/19)

0.19.x bugfix release (patch)

### 0.19.1

- Total issues resolved: **0**
- Total pull requests resolved: **4**
- Total contributors: **2**

 - [442: Cleanup:  Remove adding ext-phar for build in Dockerfile](https://github.com/perftools/xhgui/pull/442) thanks to @glensc
 - [441: Set GIT_AUTHOR_NAME/GIT_AUTHOR_EMAIL via env rather secrets](https://github.com/perftools/xhgui/pull/441) thanks to @glensc
 - [438: Feature: Add driver name to PdoRepository](https://github.com/perftools/xhgui/pull/438) thanks to @glensc
 - [436: Implement pdo: getForUrl(), getPercentileForUrl(), getAll()](https://github.com/perftools/xhgui/pull/436) thanks to @fengqi

Expected behavior

markdown source

### Release Notes for [0.19.1](https://github.com/perftools/xhgui/milestone/19)

0.19.x bugfix release (patch)

### 0.19.1

Summary:
- Total issues resolved: **0**
- Total pull requests resolved: **4**
- Total contributors: **2**

Pull requests:
 - [442: Cleanup:  Remove adding ext-phar for build in Dockerfile](https://github.com/perftools/xhgui/pull/442) thanks to @glensc
 - [441: Set GIT_AUTHOR_NAME/GIT_AUTHOR_EMAIL via env rather secrets](https://github.com/perftools/xhgui/pull/441) thanks to @glensc
 - [438: Feature: Add driver name to PdoRepository](https://github.com/perftools/xhgui/pull/438) thanks to @glensc
 - [436: Implement pdo: getForUrl(), getPercentileForUrl(), getAll()](https://github.com/perftools/xhgui/pull/436) thanks to @fengqi

Can’t figure why tags action does not fire

Bug Report

I’ve set up the integration to build docker images:

• perftools/xhgui#428

I’ve read the readme, that needs to use org token:

• perftools/xhgui#431

but still, the events for git push don’t fire:

• https://github.com/perftools/xhgui/actions/workflows/docker.yml

it should build on pushed tags *.*.*, for example, 0.19.0:

• https://github.com/perftools/xhgui/blob/0.19.0/.github/workflows/docker.yml#L12-L13

---

This is re-post of the forum post, since seems this project maintainers do not follow forums:

• https://discourse.laminas.dev/t/support-automatic-releases-cant-figure-why-tags-action-does-not-fire/2586

Ensure that merge-up PRs

Feature Request

Depends on #26

Assuming a "next milestone" already exists, when creating a pull request from a stable release branch to the next release branch, the tool must assign the correct milestone to the created pull request.

See doctrine/automatic-releases#37

Q	A
New Feature	yes
RFC	yes
BC Break	no

`laminas/automatic-releases` action cannot be built due to missing `.git` directory in the build environment

Github actions perform a docker build in an environment that is a clean export of the repository snapshot (without history), but our Dockerfile has:

automatic-releases/Dockerfile

Lines 33 to 35 in ea00621

	ADD .git /app/.git
	ADD bin /app/bin
	ADD src /app/src

This is failing because .git doesn't exist. The .git directory is needed for ocramius/package-versions to detect the specific version of the action being built, but we can ignore this version for now.

Use CHANGELOG format in releases

Feature Request

Q	A
New Feature	yes
RFC	yes
BC Break	no

Summary

It was mentioned in chat that we should be using CHANGELOG format for tag/release descriptions. This needs more work to be implemented, so mainly opening this as a placeholder for intended future implementation.

Configure release branch prefix

Feature Request

Q	A
New Feature	yes
RFC	no?
BC Break	no

Summary

I would love to use the tool for managing the releases for my companies packages. Back in the days, we decided to add a prefix to our release branches (e.g. /releases/). Since I would love to keep that, I am wondering if you are open to add a configuration option that would allow this behavior.

This would basically mean to introduce a new env var that defines the release branch prefix and extend the \Laminas\AutomaticReleases\Git\Value::isReleaseBranch() to deal with the branch prefix. If the env var is not defined or empty, the current behavior is kept.

Happy to work on this if it makes sense for you.

Create next milestones after a release is prepared

Feature Request

See doctrine/automatic-releases#26

After a release is done, we want to implicitly generate new milestones.

Given following milestones:
  | name |
  | 1.0.0 |
When milestone 1.0.0 is closed
Then following milestones should exist:
  | name |
  | 1.0.1 |
  | 1.1.0 |
  | 2.0.0 |

This should probably be done as a new command to be added to the automatic-release workflow example.

Note: the command must gracefully ignore pre-existing milestones with same names, and duplicate milestone names must never be possible!

Q	A
New Feature	yes
RFC	no
BC Break	no

`git` broken on latest `1.14.0` image

Bug Report

1.14.0 crashes and leaks repository secrets.

Q	A
Version(s)	1.14.0

Summary

The 1.14.0 image has now been dropped, as a security precaution.

Two problems arise:

1. in case of git operations failing, we get a crash with un-masked secrets (really bad, although not exploitable, luckily)
2. because git added "security" around operating on repositories owned by other users, we have crashing release processes, like https://github.com/scoutapp/scout-apm-php-ext/runs/7518545888?check_suite_focus=true

Related: laminas/laminas-continuous-integration-action#99

Merge up PR creation step fails when no changes to merge up

Bug Report

Q	A
Version(s)	x.y.z

Summary

In unusual conditions I had to trigger 2.13.1 patch release that had no changes to merge up to 2.14.x due to laminas/laminas-navigation#28

Attempt to create merge-up PR failed since it would have ended up with empty changeset.

https://github.com/laminas/laminas-navigation/runs/4503567078?check_suite_focus=true#step:5:1

Current behavior

Merge up PR creation fails when there are no changes to merge up.

In invariant_violation.php line 18:
                                                     
  [Psl\Exception\InvariantViolationException]        
  Failed to create pull request through GitHub API.  
                                                     

Exception trace:
  at /app/vendor/azjezz/psl/src/Psl/invariant_violation.php:18
 Psl\invariant_violation() at /app/vendor/azjezz/psl/src/Psl/invariant.php:21
 Psl\invariant() at /app/src/Github/Api/V3/CreatePullRequestThroughApiCall.php:65
 Laminas\AutomaticReleases\Github\Api\V3\CreatePullRequestThroughApiCall->__invoke() at /app/src/Application/Command/CreateMergeUpPullRequest.php:109
 Laminas\AutomaticReleases\Application\Command\CreateMergeUpPullRequest->execute() at /app/vendor/symfony/console/Command/Command.php:256
 Symfony\Component\Console\Command\Command->run() at /app/vendor/symfony/console/Application.php:971
 Symfony\Component\Console\Application->doRunCommand() at /app/vendor/symfony/console/Application.php:290
 Symfony\Component\Console\Application->doRun() at /app/vendor/symfony/console/Application.php:166
 Symfony\Component\Console\Application->run() at /app/bin/console.php:171
 Laminas\AutomaticReleases\WebApplication\{closure}() at /app/bin/console.php:172

laminas:automatic-releases:create-merge-up-pull-request

How to reproduce

Trigger release when released branch and next branch have all changes already

Expected behavior

Probably, detect no changes condition and skip PR creation

`CHANGELOG.md` bump failed for branch with valid changelog?

Bug Report

See https://github.com/Ocramius/PackageVersions/actions/runs/213423994

Q	A
Version(s)	1.2.4

Didn't manage to investigate further, but changelog commit seemed to fail due to no generated diff (by the changelog bump tool)

Release for a private repository

Bug Report

I've been using automatic-releses for my open-source projects for some time, but yesterday I tried on a private repository and I'm getting a 422 error during fetchMilestoneIssues.

Q	A
Version(s)	<=1.12.0

Summary

If I try to release to a private repository, the fetchMilestoneIssues within the jwage/changelog-generator fails with a 422 error because it does not have the github credentials.

I tested on 1.11.1 and 1.12.0. I'm opening a PR for a fix in a few minutes.

Current behavior

In IssueClient.php line 56:
  [RuntimeException]
  API call to GitHub failed with status code 422 and message "Validation Failed"

Exception trace:
  at /app/vendor/jwage/changelog-generator/src/ChangelogGenerator/IssueClient.php:56
 ChangelogGenerator\IssueClient->execute() at /app/vendor/jwage/changelog-generator/src/ChangelogGenerator/IssueFetcher.php:32
 ChangelogGenerator\IssueFetcher->fetchMilestoneIssues() at /app/vendor/jwage/changelog-generator/src/ChangelogGenerator/IssueRepository.php:24
 ChangelogGenerator\IssueRepository->getMilestoneIssues() at /app/vendor/jwage/changelog-generator/src/ChangelogGenerator/ChangelogGenerator.php:36
 ChangelogGenerator\ChangelogGenerator->generate() at /app/src/Github/JwageGenerateChangelog.php:54
 Laminas\AutomaticReleases\Github\JwageGenerateChangelog->__invoke() at /app/src/Github/CreateReleaseTextThroughChangelog.php:50
 Laminas\AutomaticReleases\Github\CreateReleaseTextThroughChangelog->__invoke() at /app/src/Github/MergeMultipleReleaseNotes.php:39
 Laminas\AutomaticReleases\Github\MergeMultipleReleaseNotes::Laminas\AutomaticReleases\Github\{closure}() at /app/vendor/azjezz/psl/src/Psl/Vec/map.php:38
 Psl\Vec\{closure}() at n/a:n/a
 array_map() at /app/vendor/azjezz/psl/src/Psl/Vec/map.php:39
 Psl\Vec\map() at /app/src/Github/MergeMultipleReleaseNotes.php:40
 Laminas\AutomaticReleases\Github\MergeMultipleReleaseNotes->__invoke() at /app/src/Application/Command/ReleaseCommand.php:86
 Laminas\AutomaticReleases\Application\Command\ReleaseCommand->execute() at /app/vendor/symfony/console/Command/Command.php:256
 Symfony\Component\Console\Command\Command->run() at /app/vendor/symfony/console/Application.php:971
 Symfony\Component\Console\Application->doRunCommand() at /app/vendor/symfony/console/Application.php:290
 Symfony\Component\Console\Application->doRun() at /app/vendor/symfony/console/Application.php:166
 Symfony\Component\Console\Application->run() at /app/bin/console.php:169
 Laminas\AutomaticReleases\WebApplication\{closure}() at /app/bin/console.php:170

laminas:automatic-releases:release

How to reproduce

Install the action on a private repository.

Expected behavior

Release done successfully.

Create author links in CHANGELOG file

Feature Request

Add links to all pull request authors in the CHANGELOG.md file.

Q	A
New Feature	yes
RFC	no
BC Break	no

Summary

When looking a the release page and comparing it to the CHANGELOG file, there is a difference in the generated output.

The release description got links to the original pull request author, while the CHANGELOG file does not. AFAIK GitHub autogenerate links for all @USER text on the release page.

Missing Git LFS support

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	no

Summary

When run on lfs git repository:

In execute.php line 82:
                                                                               
  [Psl\Shell\Exception\FailedExecutionException (1)]                           
  Shell command "git 'checkout' '1.0.x'" returned an exit code of "1".         
                                                                               
  STDOUT:                                                                      
                                                                               
                                                                               
  STDERR:                                                                      
      Already on '1.0.x'                                                       
      \nThis repository is configured for Git LFS but 'git-lfs' was not found  
   on your path. If you no longer wish to use Git LFS, remove this hook by de  
  leting '.git/hooks/post-checkout'.\n                                         
                                                                               

Exception trace:
  at /app/vendor/azjezz/psl/src/Psl/Shell/execute.php:82
 Psl\Shell\execute() at /app/src/Git/CreateTagViaConsole.php:26
 Laminas\AutomaticReleases\Git\CreateTagViaConsole->__invoke() at /app/src/Application/Command/ReleaseCommand.php:108
 Laminas\AutomaticReleases\Application\Command\ReleaseCommand->execute() at /app/vendor/symfony/console/Command/Command.php:256
 Symfony\Component\Console\Command\Command->run() at /app/vendor/symfony/console/Application.php:971
 Symfony\Component\Console\Application->doRunCommand() at /app/vendor/symfony/console/Application.php:290
 Symfony\Component\Console\Application->doRun() at /app/vendor/symfony/console/Application.php:[16](https://github.com/xxx/runs/5572604814?check_suite_focus=true#step:4:16)6
 Symfony\Component\Console\Application->run() at /app/bin/console.php:[17](https://github.com/xxx/runs/5572604814?check_suite_focus=true#step:4:17)1
 Laminas\AutomaticReleases\WebApplication\{closure}() at /app/bin/console.php:172

laminas:automatic-releases:release

Document that the merge-up branch is automatically created

Bug Report

Q	A
Version(s)	1.2.x

Summary

I had a hotfix release for a package and was suprised that a merge-up branch was created automatically. The readme should be updated as it's not mentioned.

It works very nice though.

How do I downgrade to a previous version?

Bug Report

Q	A
Version(s)	all?

Summary

I'm trying to avoid #166 by downgrading to v1.11.1 (see doctrine/orm#9061)

Current behavior

This translates into the latest version being used:

https://github.com/doctrine/orm/runs/3782330485?check_suite_focus=true#step:4:11

How to reproduce

• Use the following syntax: uses: "laminas/[email protected]"
• Close a milestone

Expected behavior

I'd expect the job logs not to mention ghcr.io/laminas/automatic-releases:1 but ghcr.io/laminas/automatic-releases:1.11.1.

Will this work with RC, beta or alpha versions

and also with 0.y.x versions?

Move open PRs to next milestone on release

Feature Request

Q	A
New Feature	yes
BC Break	no

Summary

In #90, a feature was requested to move issues from old milestones to new one.
I've recently manually moved open PRs in https://github.com/laminas/laminas-ci-matrix-action/pulls to the latest minor. One of these had a bump of 5 minor releases.

I wonder if it is possible to automatically re-target open PRs to the next milestone (major or minor) rather than keeping them untouched.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Use matchDepNames instead of matchPackageNames

Edited/Blocked

These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.

• Update PHP

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency laminas/laminas-diactoros to v3
• Update dependency phpunit/phpunit to v11
• Update dependency psr/http-message to v2
• Update dependency symfony/console to v7
• Lock file maintenance
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

composer

composer.json

• php ~8.2.0
• azjezz/psl ^2.9.1
• jwage/changelog-generator ^1.4.0
• laminas/laminas-diactoros ^2.26.0
• lcobucci/clock ^3.2.0
• monolog/monolog ^3.6.0
• ocramius/package-versions ^2.8.0
• phly/keep-a-changelog ^2.12.1
• php-http/curl-client ^2.3.2
• php-http/discovery ^1.19.4
• php-http/httplug ^2.4.0
• psr/http-client ^1.0.3
• psr/http-message ^1.1
• psr/log ^3.0.0
• symfony/console ^6.4.7
• doctrine/coding-standard ^12.0.0
• php-standard-library/psalm-plugin ^2.2.1
• phpunit/phpunit ^9.6.12
• psalm/plugin-phpunit ^0.19.0
• roave/infection-static-analysis-plugin ^1.32.0
• squizlabs/php_codesniffer ^3.7.2
• vimeo/psalm ^5.15.0

dockerfile

Dockerfile

• composer 2
• php 8.2-alpine

github-actions

.github/workflows/build-and-push-containers.yml

• actions/checkout v4
• docker/setup-qemu-action v3
• docker/setup-buildx-action v3
• docker/login-action v3
• docker/build-push-action v5

.github/workflows/continuous-integration.yml

.github/workflows/docker-build.yml

• actions/checkout v4

.github/workflows/release-on-milestone-closed.yml

.github/workflows/update-major-release.yml

---

• Check this box to trigger a request for Renovate to run again on this repository

Does not checkout release branch before attempting to update changelog

Bug Report

Q	A
Version(s)	1.2.1

Summary

The laminas:automatic-releases:release command fails when attempting to commit the release date to the CHANGELOG.md file when the default branch is other than the release branch.

As a specific example: I recently attempted to close milestone 2.12.3 of laminas-mail. A 2.13.x branch already exists. When it attempted to push changes for the changelog, I received the error here: https://github.com/laminas/laminas-mail/runs/977187215?check_suite_focus=true#step:4:14

How to reproduce

Create a release branch "X.Y.x", and another "X.Y+1.x". Close a milestone related to "X.Y.x".

Expected behavior

It should check out the associated release branch prior to updating the changelog so that it can commit and push to it.

Support pre-releases such as `1.0.0-alpha1`, `1.0.0-beta2`, `1.0.0-rc5`

Feature Request

See doctrine/automatic-releases#25

Currently the tool does not understand milestones named (\d+)\.(\d+)\.(\d+)\-(alpha|beta|rc)(\d*), nor knows how to sort them.

We want to support pre-release versions such as:

• 1.0.0-alpha1
• 1.0.0-beta32
• 1.0.0-rc99

This requires expansion of the SemVerVersion value object, but should otherwise operate as usual. The only tricky part is sorting versions.

Q	A
New Feature	yes
RFC	no
BC Break	no

refusing to allow a GitHub App to create or update workflow `.github/workflows/continuous-integration.yml` without `workflows` permission

Bug Report

Q	A
Version(s)	all (but only troubleshootable on 1.11.1 or lower)

Summary

laminas:automatic-releases:release fails

Current behavior

When attempting to push the tag, the push is rejected with the message in the title.

See https://github.com/doctrine/orm/runs/3782647862?check_suite_focus=true

How to reproduce

Not quite sure how to reproduce: it did not happen on branch 2.9.x

Expected behavior

No error

Normalize generated changelog to remove redundant information and whitespace

Feature Request

Q	A
New Feature	enhancement
RFC	no
BC Break	no

Summary

Currently, the jwage/changelog-generator -generated content includes:

-----

### Release Notes for [1.0.0](https://github.com/mezzio/mezzio-cors/milestone/1)



### 1.0.0

Note:

• the extra line breaks
• the repeated "1.0.0" references

The suggestion is to normalize this to:

• never have more than one empty line at a time
• remove the extraneous version references

Document the process of creating a subkey

[…] 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.

For non-experienced in GnuPG users like myself, it will be helpful to have more detailed documentation on creating the signing subkey and exporting it to GitHub.

Remove empty changelog sections when creating changelog from Keep A Changelog format

Feature Request

Q	A
New Feature	improvement
RFC	no
BC Break	no

Summary

Currently when using Keep A Changelog-formatted changelogs, it's not uncommon to have entries that look like this:

## X.Y.Z - TBD

### Added

- Nothing.

### Changed

- Nothing.

### Removed

- Nothing.

### Deprecated

- Nothing.

### Fixed

- Something we fixed

This leads to a lot of noise in the generated changelogs, as we have a lot of "Nothing" entries, followed by a list of things we actually did.

The suggested improvement is to find ### {heading}\n\nNothing.\n entries and remove them as part of changelog fetching and normalization.

Automate release announcement on twitter

Feature Request

I find myself always having to announce a release on twitter after closing a milestone.

While that's nice (added visibility), it is also something that could maybe be automated, although unsure how to formulate a meaningful tweet from it.

Q	A
New Feature	yes
RFC	yes
BC Break	no

Lables usage and documentation is missing

Feature Request

Q	A
New Feature	yes
RFC	yes/no
BC Break	yes/no

Summary

The release generation process seems to use labels somehow:

• https://github.com/laminas/laminas-mail/releases/tag/2.13.0

The changelog items seem to be categorized by the labels:

Bug
129: Tests: Resolve duplicate data provider key thanks to @glensc
125: Merge release 2.12.5 into 2.13.x thanks to @github-actions[bot]

Duplicate,Enhancement
127: phpunit9 and php8 thanks to @delboy1978uk

Enhancement
117: Add PHP 8.0 support thanks to @bfoosness
109: Code style fixes in tests thanks to @glensc
101: Fixes #34 replace call_user_func* with self invoked function thanks to @samsonasik
34: replace call_user_func* with self invoked function thanks to @michalbundyra

I checked README.md and found no match for labels being documented.