Hello 👋,

Thanks for this great tooling. I've got a minor feature request which would help save a few clicks on the consumers end - would we be able to automatically delete release branches after they have been merged or marked inactive?

• Summary/Changelog - only list "Update Documentation" once
• Summary/Changelog - Ordering: (Add, Remove, Deprecate, Documentation)

Somewhere around this release PR the packages listed under the replace keyword in google-cloud-php's composer.json file stopped being updated. The timing seems to coincide with the following refactor: #262

Example: googleapis/java-core@8b87caa

This should update the version of this artifact and the version of the parent (both have the region tags set).

🤖 Here's what the next release of release-please would look like.

1.3.1 (2019-05-16)

Bug Fixes

• GitHub issues do not allow 'link comments' (#92) (fe4cd4f)
• Node 10 is required for async/await (#89) (c795eef)

• Should I create this release for you 🤖?

We would like to take advantage of the conventional commits feature allowing highlighting of breaking changes, but Release Please considers any breaking change to be a major version update, even in pre-1.0 packages.

Release Please should increment the minor version for breaking changes when a package is in its pre-1.0 state rather than bumping to 1.0 (i.e. GA).

Thanks!

the test coverage on release-please is quite low, I'd like to put some work into increasing it (now that we're starting to roll out to a wider audience).

If we merge a feature, but then revert it, before the next release, we should be able to ignore the original PR from both the release history and the rules for version bumping.

🤖 Here's what the next release of release-please would look like.

1.4.2 (2019-05-17)

• Should I create this release for you 🤖?

🤖 This issue was created by robots! 🤖.

Its purpose is to show you what the next release of release-please would look like... If we published it right now.

1.2.0 (2019-05-10)

Bug Fixes

• candidate issue should only be updated every 15 minutes. (#70) (edcd1f7)

Features

• add GitHub action for generating candidate issue (#69) (6373aed)

[ ] Please open a PR for this release

I noticed that 🤖 created a release PR over here with no changes:
googleapis/nodejs-gce-images#147

We probably don't want to create those PRs if there are no applicable things to include.

Release please doesn't show all lines of a conventional commit body if it has a bullet point with multiple lines, where the lines are indented to indicate they are a continuation of the point.

For example, this commit kicked off this release, which added this commit. Both the release PR description and the CHANGELOG commit are only showing the first line of each bullet point.

I would like to be able to use release-please to manage the automatic release of Terraform modules (including changelog updates).

For example: terraform-google-modules/terraform-google-network#145

🤖 Here's what the next release of release-please would look like.

1.3.1 (2019-05-16)

Bug Fixes

• GitHub issues do not allow 'link comments' (#92) (fe4cd4f)
• Node 10 is required for async/await (#89) (c795eef)

• Should I create this release for you 🤖?

Some projects have a nice section of the release notes in GitHub that includes all the usernames of people who submitted contributions to that release.

I'm noticing an unhandled rejection when running the test suite:

(node:227540) UnhandledPromiseRejectionWarning: HttpError: request to https://api.github.com/repos/googleapis/java-trace/issues/1/labels failed, reason: Nock: No match for request {
  "method": "POST",
  "url": "https://api.github.com/repos/googleapis/java-trace/issues/1/labels",
  "headers": {
    "accept": [
      "application/vnd.github.v3+json"
    ],
    "user-agent": [

🤖 Here's what the next release of release-please would look like.

1.4.1 (2019-05-16)

• Should I create this release for you 🤖?

Hello! Autosynth couldn't regenerate release-please. 💔

Here's the output from running synth.py:

Cloning into 'working_repo'...
Switched to branch 'autosynth'
Traceback (most recent call last):
  File "/home/kbuilder/.pyenv/versions/3.6.1/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/kbuilder/.pyenv/versions/3.6.1/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/tmpfs/src/git/autosynth/autosynth/synth.py", line 256, in <module>
    main()
  File "/tmpfs/src/git/autosynth/autosynth/synth.py", line 196, in main
    last_synth_commit_hash = get_last_metadata_commit(args.metadata_path)
  File "/tmpfs/src/git/autosynth/autosynth/synth.py", line 149, in get_last_metadata_commit
    text=True,
  File "/home/kbuilder/.pyenv/versions/3.6.1/lib/python3.6/subprocess.py", line 403, in run
    with Popen(*popenargs, **kwargs) as process:
TypeError: __init__() got an unexpected keyword argument 'text'

Google internal developers can see the full log here.

The release PR #207 is still in a pending state after several hours

🤖 This issue was created by robots! 🤖.

Its purpose is to show you what the next release of release-please
would look like... If you published it right now.

If you're a maintainer, and would like create a PR for this release,
simply comment on this issue.

1.0.0 (2019-05-10)

Bug Fixes

• add ^ to dependency in samples/package.json (114a721)
• allow executable (#11) (2b0219e)
• could not handle the very first release of a library before it had any tags. (#24) (145fa1e)
• log message was printing undefined version (#15) (1724969)
• shebang must be first line (e8fe4bb)
• support H2 and H3 CHANGELOG headings (#6) (39fd82f)
• there was a typo in failure output (#61) (28e1489)

Build System

• upgrade engines field to >=8.10.0 (#9) (49e7684)

Features

• add a label to the release PR for automation (#4) (c3f0588)
• adding a WIP GitHub action for minting releases (#27) (b159ef3)
• adds support for updating release-dependent files in simple Node repo (#1) (775c0a8)
• initial commit of library (c6dc492)
• you must now opt in to bumping minor pre-major (#10) (f438ced)

BREAKING CHANGES

• prior to this the minor was bumped rather than major for pre-major releases
• upgrade engines field to >=8.10.0 (#9)

🤖 This issue was created by robots! 🤖.

Its purpose is to show you what the next release of release-please would look like... If we published it right now.

1.2.0 (2019-05-10)

Bug Fixes

• candidate issue should only be updated every 15 minutes. (#70) (edcd1f7)

Features

• add GitHub action for generating candidate issue (#69) (6373aed)

[ ] Please open a PR for this release

🤖 Here's what the next release of release-please would look like.

1.4.1 (2019-05-16)

release created at #104

comments to this issue should not result in a release being made.

we've split out the release logic into specific languages, e.g., ruby-yoshi, node, let's actually add some tests for each language.

to allow a bump from 0.x.x to 1.0.0, let's allow folks to provide a Relese-As: footer, it would look something like this:

feat: we are going ga \o/

Release-As: 1.0.0

'Allo! I was just looking at this generated release, and I was thinking it would be nice if the BREAKING CHANGES came first on the list for maximum visibility. Actually, maybe even jazzing it up wouldn't be going too far:

⚠️ Breaking Changes!

testing the concept of a next release issue, which will always contain information about the next release that would go out the door.

Kokoro was experiencing an outage and we needed to get a release out so we manually tagged, circumventing the autorelease process. This prevented subsequent release PRs from being generated with the failure message command github-release failed with status 401 (See full log here).

As per @bcoe's suggestion, adding the autorelease-closed label to the release PR resolved the 401 - but it may be worth further investigating why this occurred in the first place.

The release PR #211 is still in a pending state after several hours

🤖 Here's what the next release of release-please would look like.

1.3.1 (2019-05-16)

Bug Fixes

• GitHub issues do not allow 'link comments' (#92) (fe4cd4f)
• Node 10 is required for async/await (#89) (c795eef)

• Should I create this release for you 🤖?

🤖 Here's what the next release of release-please would look like.

1.3.1 (2019-05-16)

Bug Fixes

• GitHub issues do not allow 'link comments' (#92) (fe4cd4f)
• Node 10 is required for async/await (#89) (c795eef)

[//]: # footer follows.

• Should I create this release for you 🤖?

For a new artifact, release-please is unable to propose the initial release.

Example: https://github.com/googleapis/java-shared-config would like to release 0.1.0 as its initial version

✔ found 9 commits since undefined
✖ no user facing commits found since beginning of time

The release PR #139 is still in a pending state after several hours

If the latest released version of a library is 14.0.0, and a tag exists pointing to 14.2.0 (perhaps it was pointing to another branch), release please fails to determine the next release.

I noticed that we seem to have a lot of PRs getting closed, and re-opened with no changes:

It's generating a fair bit of notification noise, so I wonder if we can't first check if there is a PR open, and if it's latest commit # matches the previous one?

fenster-macbookpro:release-please fenster$ node --version
v8.16.0

fenster-macbookpro:release-please fenster$ node ./build/src/bin/release-please.js mint-release --package-name=@google/repo [email protected]:googleapis/github-repo-automation.git
release-please.js mint-release

mint a new release for a repo

Options:
  --help                  Show help                                    [boolean]
  --version               Show version number                          [boolean]
  --token                 GitHub repo token
                           [default: "zzzzzz"]
  --package-name          name of package release is being minted for [required]
  --repo-url              GitHub URL to generate release for          [required]
  --release-type          what type of repo is a release being created for?
                                                               [default: "node"]
  --bump-minor-pre-major  should we bump the semver minor prior to the first
                          major release               [boolean] [default: false]
  --label                 label to add to generated PR
                                               [default: "autorelease: pending"]

TypeError: Symbol.asyncIterator is not defined.
    at __asyncValues (/Users/fenster/release-please/build/src/github.js:26:38)
    at GitHub.<anonymous> (/Users/fenster/release-please/build/src/github.js:100:31)
    at Generator.next (<anonymous>)
    at /Users/fenster/release-please/build/src/github.js:22:71
    at new Promise (<anonymous>)
    at __awaiter (/Users/fenster/release-please/build/src/github.js:18:12)
    at GitHub.allTags (/Users/fenster/release-please/build/src/github.js:96:16)
    at GitHub.<anonymous> (/Users/fenster/release-please/build/src/github.js:81:37)
    at Generator.next (<anonymous>)
    at /Users/fenster/release-please/build/src/github.js:22:71

$ jq .engines.node package.json 
">=8.10.0"

I guess the engines must be updated to support only those versions of Node.js that have async iterators.

Looking at google-api-java-client, there was a long tail of files we failed to update the version in:

./google-api-client/src/test/java/com/google/api/client/googleapis/GoogleUtilsTest.java:    String version = "1.30.3";
./google-api-client/src/test/java/com/google/api/client/googleapis/GoogleUtilsTest.java:    String version = "1.30.3-SNAPSHOT";
./google-api-client/src/main/java/com/google/api/client/googleapis/GoogleUtils.java:  public static final String VERSION = "1.30.3".toString();
./google-api-client-bom/README.md:      <version>1.30.3</version>

We continue to add one off fixes, like #304, but it might be nice to have a slightly more generic update class that handles a variety of simple string replacements.

e.g., <version>0.3.0</version>, VERSION = "0.20.4", maybe the class could support a variety of regexes like releasetool.

We should export the public interface types for this library so downstream users don't need to reach into the source for importing types.

I was taking a look at this PR:
googleapis/nodejs-tasks#279

It looks like any time there was a push to master while the PR was open, the release PR got closed and then re-opened. Every time this happens, it pushes another GitHub notification to anyone watching the repo, and generally just generates a lot of noise. It would be nice to clean this up :)

The snapshot bump PRs should not actually create releases so it should not add the autorelease label to the PR

In a recent release of c8, the release notes were not extracted correctly from CHANGELOG.md, see:

Just for tracking purposes, would be great to get this added to https://github.com/googleapis/sloth/blob/master/repos.json

could we fetch the packageName from the repository itself, we already pull in package.json to update it... perhaps we could load the package.json earlier in the process, and use this value to override the packageName set in configuration.

On gax-nodejs I saw that the first commit after landing the bot came through. The bot seems to close the existing release PR, and then just open a new one. Is it worth having the bot force push it's changes on the same PR instead of creating a new one?

Now that I have the bot set up in google/gts#390, I noticed that all of the commits have [skip ci] on them. This, predictably, is causing CI to get skipped :)

🤖 Here's what the next release of release-please would look like.

1.4.1 (2019-05-16)

• Should I create this release for you 🤖?

🤖 This issue was created by robots! 🤖.

Its purpose is to show you what the next release of release-please would look like... If we published it right now.

1.2.0 (2019-05-10)

Bug Fixes

• candidate issue should only be updated every 15 minutes. (#70) (edcd1f7)

Features

• add GitHub action for generating candidate issue (#69) (6373aed)

[ ] Please open a PR for this release

There are always gonna be a few releases we sit on for a bit. It seems like something is happening in a nightly cron somehow that's triggering the tool to get run:

It would be awesome if it only ran after things landed into master :)

🤖 Here's what the next release of release-please would look like.

1.2.0 (2019-05-10)

Bug Fixes

• candidate issue should only be updated every 15 minutes. (#70) (edcd1f7)

Features

• add GitHub action for generating candidate issue (#69) (6373aed)

release created at #78

🤖 Here's what the next release of release-please would look like.

1.3.1 (2019-05-16)

Bug Fixes

• GitHub issues do not allow 'link comments' (#92) (fe4cd4f)
• Node 10 is required for async/await (#89) (c795eef)

release created at #99