Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve logic to generate nightly release notes #19553

Merged
merged 1 commit into from Jun 18, 2019

Conversation

@rafeca
Copy link
Contributor

commented Jun 17, 2019

This PR tweaks the logic that calculates the release notes for nightly releases (which are saved on the atom-nightly-releases repo: https://github.com/atom/atom-nightly-releases/releases) to be more resilient and always give at least some meaningful information.

Context

The previous logic only displayed a message with a link to the compare URL with the previous version, and used that same message from the previous version to get the commit from that previous version.

This caused a domino effect whenever one single nightly release went wrong: if release notes could not be calculated, this was propagated to future nightlies until somebody manually wrote the release notes of a version.

This has caused empty release notes for months.

Solution

In order to avoid this scenario, the release notes now contain two parts:

  1. the first one shows the commit id of this release. This is independant from previous releases and will be displayed in every release (unless something really bad goes on).
  2. the second part is the compare URL. To calculate this one we first try to find the previous release and then its release notes. If for some reason we fail doing so, this whole part is not displayed.

This logic allows self-recovery of the release notes: even if there are failures while calculating the release notes of a nightly release, future releases will be able to recover correctly.

Finally, this is a couple of screenshots of how the new release notes are displayed:

Screenshot 2019-06-17 at 20 42 11

Screenshot 2019-06-17 at 20 42 30

@rafeca rafeca requested review from nathansobo, jasonrudolph and as-cii Jun 17, 2019

@nathansobo
Copy link
Contributor

left a comment

This seems fine, but is there any way we could grab the previous release's revision SHA from its tag rather than by scraping it out of the release notes? Found a stray log statement.

const previousRelease = getPreviousRelease(releaseVersion, releases.data);
const oldReleaseNotes = previousRelease ? previousRelease.body : undefined;

console.log('foooooooo', previousRelease);

This comment has been minimized.

Copy link
@nathansobo

nathansobo Jun 17, 2019

Contributor

🔥?

This comment has been minimized.

Copy link
@rafeca

rafeca Jun 17, 2019

Author Contributor

uppps 😅

@rafeca rafeca force-pushed the release-notes-on-nightly branch from 8596142 to c67794c Jun 17, 2019

@rafeca

This comment has been minimized.

Copy link
Contributor Author

commented Jun 17, 2019

This seems fine, but is there any way we could grab the previous release's revision SHA from its tag rather than by scraping it out of the release notes? Found a stray log statement.

The problem is that nightly releases live in a separate repo (e.g https://github.com/atom/atom-nightly-releases/releases/tag/v1.39.0-nightly20), with no direct access to the real commit from atom/atom that originated it.

Maybe we could add the SHA1 of the commit to the tag, but not sure if that would mess up with other parts of the release infra...

Another option would be to create tags on atom/atom potinting to each nightly, but that would mean tooons of tags created.

@nathansobo

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

Another option would be to create tags on atom/atom potinting to each nightly, but that would mean tooons of tags created.

I would actually be okay with this. It seems useful to me. But I'm also fine leaving things as they are. I figured there was probably a good reason you did it this way but wanted to clarify.

@rafeca

This comment has been minimized.

Copy link
Contributor Author

commented Jun 18, 2019

I figured there was probably a good reason you did it this way but wanted to clarify.

The only reason is that this is the way it was done before this PR 😅 and didn't want to change drastically the way nightly releases work without fully understanding the whole flow.

Maybe we can revisit the whole nightly releases flow separately and rethink some aspects about how it works, e.g:

  • Do we need to publish the releases on a separate repository?
  • Is it fine if we publish the nightlies along the stable and beta versions
    in https://github.com/atom/atom/releases, or will it create too much noise?
  • Should we keep publishing the nightlies in a separate repo but create tags for them on the main repo?

@rafeca rafeca requested a review from nathansobo Jun 18, 2019

@rafeca rafeca merged commit e05bb34 into master Jun 18, 2019

1 check passed

Atom Pull Requests #20190617.11 succeeded
Details

@rafeca rafeca deleted the release-notes-on-nightly branch Jun 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.