laminas / automatic-releases Goto Github PK

Feature Request

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.

and also with 0.y.x versions?

Feature Request

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.

Bug Report

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.

Feature Request

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

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.

Feature Request

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.

Feature Request

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.

Bug Report

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

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 🤔

Feature Request

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)

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

Bug Report

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

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:

Feature Request

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

Feature Request

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.

Bug Report

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

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

Feature Request

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

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

Bug Report

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

### 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

### 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

Feature Request

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.

RFC

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.

Bug Report

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).

Feature Request

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

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

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.

Feature Request

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.

Feature Request

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).

Bug Report

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.

Bug Report

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?)

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!

Feature Request

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.

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.

Bug Report

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.

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.

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.

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.

Bug Report

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.

Feature Request

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

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

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.

Feature Request

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.

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).

Summary

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

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

Bug Report

1.14.0 crashes and leaks repository secrets.

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

Bug Report

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.

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

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

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.

Bug Report

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.

Feature Request

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
}

Feature Request

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.

Bug Report

Summary

This is a known limitation currently.

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