Release gcp-metadata v0.7.0

[ofrobots]

This pull request was generated using releasetool.

[ofrobots]

/cc @JustinBeckwith @theacodes. releasetools seems to work fairly well. It would be nice if the destination of the Changelog was configurable. Instead of the CHANGELOG.md, I would strongly prefer it if a GitHub release was drafted with the content that is currently being put into CHANGELOG.md.

[ofrobots]

Rehosted changes as a GitHub release: https://github.com/stephenplusplus/gcp-metadata/releases/edit/untagged-449ca68437e301310b2b.

[codecov-io]

Codecov Report

Merging #64 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #64   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           1      1           
  Lines          49     49           
  Branches        9      9           
=====================================
  Hits           49     49

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5e74a0e...14d05ea. Read the comment docs.

[JustinBeckwith]

@ofrobots I believe releasetool tag will do exactly what you're saying :) . So you run releasetool start to create the PR, and after the PR lands you run releasetool tag to create the release on GitHub, and add the changelog for that release.

[ofrobots]

Sounds good. But I don't actually want a changelog in the repo.

[JustinBeckwith]

I don't know, I've kinda come around to the idea. It's nice that the changelog is right there in PR. As long as a tool maintains it, it doesn't bother me 🤷‍♂️

[theacodes]

We discussed this in the candidate repo & Justin and I agree on having changelog.md. we can change it if absolutely necessary, but I do think there are huge benefits to having the release notes as a reviewable part of the PR.

…

On Tue, Jul 10, 2018, 4:36 PM Ali Ijaz Sheikh ***@***.***> wrote: Sounds good. But I don't actually want a changelog in the repo. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#64 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPUcxTQ07NYlr-wXJraiKDuLUwdSQysks5uFTpqgaJpZM4VKQvh> .

[ofrobots]

I don't like a file with the commit history and release notes (i.e. metadata) checked into a git repo.

It is not the end of the world though 🤷‍♂️.

For the broadest reach, I would expect a tool to have sensible defaults, and if those don't match users' expectations, it would allow them tailor the tools' behavior. It looks great otherwise!

[ofrobots]

@theacodes I didn't see your comment until after I responded.

there are huge benefits to having the release notes as a reviewable part of the PR.

Yep, I agree with that. I don't think that a changelog committed to the repo is the best way to go about it though. I would expect a tool to generate release PRs like this: googleapis/nodejs-error-reporting#159. It would be great if releasetools could support something like this, if not by default, then through some user specified flag.

[theacodes]

The point of releasetool is to be consistent, so I don't foresee us adding any user flags to change behavior.

…

On Tue, Jul 10, 2018, 8:04 PM Ali Ijaz Sheikh ***@***.***> wrote: Merged #64 <#64>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#64 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPUc7Fc-CaqZciqyZXN4pebKMuDbeYPks5uFWsjgaJpZM4VKQvh> .

[JustinBeckwith]

If not a flag, what do you think of adding the details to the PR like @ofrobots is suggesting then? I like it.

[theacodes]

Aren't the details already in the PR in the changeset?

…

On Tue, Jul 10, 2018, 9:35 PM Justin Beckwith ***@***.***> wrote: If not a flag, what do you think of adding the details to the PR like @ofrobots <https://github.com/ofrobots> is suggesting then? I like it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#64 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPUc1a8StiUlpU2_xEf7YzdrZcuClwDks5uFYCqgaJpZM4VKQvh> .