Implement RFC 002: Atom Nightly Releases #17538

daviwil · 2018-06-19T13:09:31Z

Description of the Change

This change adds automation for producing nightly Atom releases using VSTS CI. Most of the changes are just slight modifications to Atom's existing build scripts to produce another build channel and publish those artifacts in a way that can be installed and updated when new
releases are available.

See Atom RFC 002 for more details.

Alternate Designs

See this section of RFC 002.

Why Should This Be In Core?

This is a new release channel for Atom Core!

Benefits

See this section of RFC 002.

Possible Drawbacks

There isn't a major downside to this effort since it would run in parallel to the existing Atom release process without affecting it.

Verification Process

Produced signed Nightly builds using CI and verified that they are updatable using Electron's update service on Windows and macOS (the only platforms that support Squirrel).

At this moment nightly builds are not auto-updating because I decided to switch back to using Atom's update service on atom.io. Updating will work again once I push a change to atom.io today or tomorrow to enable the Nightly channel.

Applicable Issues

None.

Remaining Tasks

There are a few remaining tasks that need to be finished before this PR can be merged:

Failing Tests

There are 4 tests that fail consistently on VSTS for no obvious reason:

macOS

keybinding-resolver package:

 KeyBindingResolverView
   when a keydown event occurs
     it displays all commands for the keydown event but does not clear for the keyup when there is no keyup binding
       TypeError: Cannot read property 'textContent' of null
         at it (/Users/vsts/agent/2.134.2/work/1/s/node_modules/keybinding-resolver/spec/keybinding-resolver-view-spec.js:91:80)
         at <anonymous>

GitHub package:

 GithubLoginModel default strategy manages passwords:
    AssertionError: assert.equal((await loginModel.getToken('test-account')), TOKEN): expected Symbol(UNAUTHENTICATED) to equal 'TOKEN'
       at Context.<anonymous> (/Users/vsts/agent/2.134.2/work/1/s/node_modules/github/test/models/github-login-model.test.js:22:18)
       at <anonymous>

GitHub package:

 GithubLoginModel SecurityBinaryStrategy manages passwords:
     Error: Command failed: security add-generic-password -s atom-github -a test-account -w TOKEN -U
 security: SecKeychainItemCreateFromContent (<default>): The specified item already exists in the keychain.
       at ChildProcess.exithandler (child_process.js:287:12)
       at emitTwo (events.js:126:13)
       at ChildProcess.emit (events.js:214:7)
       at maybeClose (internal/child_process.js:925:16)
       at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)

I'd certainly appreciate any ideas for how these issues might be diagnosed!

Future Tasks

There are other tasks that will be finished in future PRs:

Enable x86 Windows releases (VSTS currently doesn't support x86 builds) (Enable 32-bit Windows builds for Nightly channel #17668)
Automatically generate release notes for nightly releases (Automatically generate release notes for Nightly releases #17669)
Switch back to using Electron's update.electronjs.org service once it gains features that Atom needs (Migrate Atom's update distribution to Electron's update.electronjs.org service #17670)
Fix an issue in our Windows releases where different release channels can't be used side-by-side (Multiple Atom release channels can't be installed side-by-side on Windows #9247)

I'll file issues for these when this PR is approved and merged.

This change adds automation for producing nightly Atom releases using VSTS CI. Most of the changes are just slight modifications to Atom's existing build scripts to produce another build channel and publish those artifacts in a way that can be installed and updated when new releases are available.

daviwil · 2018-06-19T13:11:19Z

script/config.js


 function getChannel () {
-  if (appMetadata.version.match(/dev/)) {
+  if (process.env.BUILD_DEFINITIONNAME === 'Atom Nightly') {


This is a VSTS environment variable but I'm planning to change it to something specific to Atom

daviwil · 2018-06-19T13:11:50Z

script/config.js

+    const commitHash = result.stdout.toString().trim()
+    version += '-' + commitHash
+  } else if (channel === 'nightly') {
+    version = process.env.BUILD_BUILDNUMBER


I'll also change this env variable to something that isn't specific to VSTS

It looks like this uses the build number as Atom's version number. If that's the current behavior, how would you feel about changing it to append the build number to the version number (e.g., "1.30.0-nightly-42")?

This was actually the case but it wasn't super clear since I was using VSTS' environment variable :) At this point in the code, I had configured the build to use the full 1.30.0-nightly42 version as the "build number". I've since changed it to use a more Atom-specific environment variable that gets set in the VSTS YAML config.

daviwil · 2018-06-19T13:12:42Z

script/lib/create-windows-installer.js


 module.exports = (packagedAppPath) => {
-  const archSuffix = process.arch === 'ia32' ? '' : '-' + process.arch
+  // const archSuffix = process.arch === 'ia32' ? '' : '-' + process.arch


This and the other commented line below will be uncommented once atom.io changes are merged/deployed.

daviwil · 2018-06-19T13:13:29Z

script/lib/create-github-release.js

@@ -0,0 +1,30 @@
+'use strict'


This file wasn't supposed to make it in, will take it back out

daviwil · 2018-06-19T13:14:22Z

script/vsts/nightly-release.yml

@@ -0,0 +1,39 @@
+name: 1.29.0-nightly$(Rev:r)


Need to find a way to pull this version number from package.json on master so that it doesn't need to be updated manually each time we roll the railcars

jasonrudolph

@daviwil: Thanks for getting this going. ⚡

I've included a few questions inline in the review below.

In addition to those inline questions, I have a few higher-level questions/notes:

What happens if I'm using the nightly release channel, and Atom's master branch hasn't had any new commits in more than 24 hours? Does a new nightly release still get created?
What happens if the nightly build fails for one platform and passes for the other platforms? Does the nightly release get created for the platforms where the build succeeded?
The task list says:
- Fix or disable tests that fail on VSTS (more info below)
I have a fairly strong preference that we fix those tests instead of disabling them. 🙏

jasonrudolph · 2018-06-20T16:41:33Z

script/config.js

+    const commitHash = result.stdout.toString().trim()
+    version += '-' + commitHash
+  } else if (channel === 'nightly') {
+    version = process.env.BUILD_BUILDNUMBER


It looks like this uses the build number as Atom's version number. If that's the current behavior, how would you feel about changing it to append the build number to the version number (e.g., "1.30.0-nightly-42")?

jasonrudolph · 2018-06-20T16:45:41Z

script/lib/create-windows-installer.js

+        fs.unlinkSync(nupkgPath)
+      } else {
+        if (process.arch === 'x64') {
+          const newNupkgPath = `${CONFIG.buildOutputPath}/atom-x64${path.basename(nupkgPath).slice(4)}`


What's the significance of the number 4 on this line? Could that number be extracted to a constant whose name explains the significant of the number?

4 is the length of the string atom, I'm basically ripping the front part of the original filename atom-1.30.0-nightly00-full.nupkg off so that I can replace it with atom-x64 in the build output path. I've simplified the logic here and added a comment so that the intent is clearer.

jasonrudolph · 2018-06-20T16:49:53Z

script/publish-release

+publishRelease({
+  token: process.env.GITHUB_TOKEN,
+  owner: 'atom',
+  repo: CONFIG.channel !== 'nightly' ? 'atom' : 'atom-nightly-releases',


Can you remind me why it makes sense to have a separate repository for the nightly releases?

Two reasons:

atom/atom's Releases feed will get swamped with nightly releases and it'll be harder to scan through the list to find older stable/beta releases

My goal was to use Electron's new update service for this and they use the Releases feed as the source of truth for updates. Seemed to make more sense to have it be a separate repo for now. Can always change it later!

jasonrudolph · 2018-06-20T16:54:02Z

script/vsts/linux.yml

+  steps:
+  - task: NodeTool@0
+    inputs:
+      versionSpec: 8.11.3


I think the current builds all use Node 6.9.4 [example]. Can you share the motivation for using Node 8.11.3 here?

I'm thinking that we'd want all builds (including the new nightly builds) using the same Node version.

Mainly because we now use Node 8 inside of Electron 2.0, so it's helpful to have the same JavaScript language features (async/await, improved perf) inside our build scripts. I started off using Node 6 in the builds and saw a noticable performance increase (~10 minutes saved) by switching to 8. More recently in this PR, I switched to the exact version of node in Electron 2.0, 8.9.3.

@daviwil Thanks for the insight. Can I talk you into opening a follow-up PR to replace the existing uses of Node 6 with Node 8?

atom/.travis.yml

Line 18 in 3109958

env: NODE_VERSION=6.9.4 DISPLAY=:99.0 CC=clang CXX=clang++ npm_config_clang=1

atom/appveyor.yml

Line 23 in 3109958

NODE_VERSION: 6.9.4

atom/circle.yml

Lines 20 to 21 in 3109958

- nvm install 6.9.4

- nvm use 6.9.4

Definitely, I'll send that out later today!

simurai · 2018-06-21T08:48:26Z

Enlist @simurai's help to produce a special icon color for the Nightly release channel (purple shade?)

How about:

Are the stars too cheesy? 😄 It's a hint for "nightly". It would also differ from the rest that only have different hues, maybe ok.

I was also thinking to replace all icons and redesign them with the "portal style" from atom.io. But that could also be done in a later PR.

thomasjo · 2018-06-21T08:57:51Z

@simurai I absolutely love that! Sure, it might be a little bit "cheesy", but 🧀 is delicious ❤️

maxbrunsfeld · 2018-06-21T16:16:08Z

OMG @simurai that is awesome.

daviwil · 2018-06-21T17:26:05Z

Love it @simurai! Definitely makes it stand out in a clear way. I think doing an icon overhaul sometime this year in the new style would also be awesome, but this icon works for now!

simurai · 2018-06-22T02:02:22Z

I think doing an icon overhaul sometime this year in the new style would also be awesome, but this icon works for now!

Ok, let's keep it in mind, but no rush. For now I added the "purple with stars" version.

daviwil

@jasonrudolph Thanks! To answer your questions:

Nightly builds only get kicked off if there have been changes to master within the last 24 hours.
If any part of the build process fails on any platform, nothing gets published. The "release" phase of the build only proceeds if all 3 platform builds and their tests pass.
I've had to disable tests in the github and keybinding-resolver packages (only on VSTS) since they will take more time to investigate and fix. I've filed issues atom/github#1568 and atom/keybinding-resolver#60, respectively, to track the need to fix these. It turns out that they're both issues that appear on other CI platforms but VSTS happens to reproduce them more consistently.

daviwil · 2018-07-09T20:56:44Z

script/lib/create-windows-installer.js

+        fs.unlinkSync(nupkgPath)
+      } else {
+        if (process.arch === 'x64') {
+          const newNupkgPath = `${CONFIG.buildOutputPath}/atom-x64${path.basename(nupkgPath).slice(4)}`


4 is the length of the string atom, I'm basically ripping the front part of the original filename atom-1.30.0-nightly00-full.nupkg off so that I can replace it with atom-x64 in the build output path. I've simplified the logic here and added a comment so that the intent is clearer.

daviwil · 2018-07-09T23:19:17Z

This PR is ready for final review! If you'd like some overall context on the process, check out the documentation I wrote up here. I'm happy to continue making improvements to the code and documentation until we feel it's ready to be merged.

Thanks!

maxbrunsfeld

This looks great!

This reverts commit 3046f68.

daviwil

Missed some other comments from Jason, sorry about that!

daviwil · 2018-07-11T13:32:40Z

script/vsts/linux.yml

+  steps:
+  - task: NodeTool@0
+    inputs:
+      versionSpec: 8.11.3


Mainly because we now use Node 8 inside of Electron 2.0, so it's helpful to have the same JavaScript language features (async/await, improved perf) inside our build scripts. I started off using Node 6 in the builds and saw a noticable performance increase (~10 minutes saved) by switching to 8. More recently in this PR, I switched to the exact version of node in Electron 2.0, 8.9.3.

daviwil · 2018-07-11T13:34:34Z

script/publish-release

+publishRelease({
+  token: process.env.GITHUB_TOKEN,
+  owner: 'atom',
+  repo: CONFIG.channel !== 'nightly' ? 'atom' : 'atom-nightly-releases',


Two reasons:

atom/atom's Releases feed will get swamped with nightly releases and it'll be harder to scan through the list to find older stable/beta releases

My goal was to use Electron's new update service for this and they use the Releases feed as the source of truth for updates. Seemed to make more sense to have it be a separate repo for now. Can always change it later!

daviwil · 2018-07-11T13:35:48Z

script/config.js

+    const commitHash = result.stdout.toString().trim()
+    version += '-' + commitHash
+  } else if (channel === 'nightly') {
+    version = process.env.BUILD_BUILDNUMBER


This was actually the case but it wasn't super clear since I was using VSTS' environment variable :) At this point in the code, I had configured the build to use the full 1.30.0-nightly42 version as the "build number". I've since changed it to use a more Atom-specific environment variable that gets set in the VSTS YAML config.

daviwil · 2018-07-11T16:33:12Z

Tests are green, issues are filed for future work. I think this is ready to be merged! Once it's in master I'll set up the scheduled build so that we start pumping out these releases on the regular :)

jasonrudolph · 2018-07-11T17:54:52Z

🚚📦:atom:

maxbrunsfeld · 2018-07-11T18:24:14Z

That was a ton of work. Nice job powering through 💥 ⚡️

daviwil · 2018-07-11T19:00:51Z

daviwil requested review from jasonrudolph and maxbrunsfeld June 19, 2018 13:09

daviwil commented Jun 19, 2018

View reviewed changes

jasonrudolph reviewed Jun 20, 2018

View reviewed changes

Replace app icons

882648c

This was referenced Jun 25, 2018

Report arbitrary release channel names atom/metrics#92

Merged

Iteration Plan: June 25 - July 6, 2018 #17579

Closed

daviwil added 3 commits June 26, 2018 10:45

Simplify channel name detection

9388a78

Upload release assets to S3 in script/publish-release

a5a8727

Generate nightly build version from package.json

ed48f2d

daviwil force-pushed the dw-nightly-releases branch from 45789f8 to ed48f2d Compare June 26, 2018 17:54

simurai mentioned this pull request Jun 28, 2018

Add custom start tiles #15975

Merged

daviwil and others added 12 commits June 28, 2018 12:52

Update app title and file paths to use channel name

9669a9b

Update atom.sh to support the nightly channel

d54bb62

Command installer should use known channel names

691d5da

Detect any channel name in AtomEnvironment.getReleaseChannel

bd5d258

Use atom.io update endpoint for Windows installer builds

ff0cd4c

Temporarily disable Atom tests on VSTS

067bd1a

Use Node.js 8.9.3 in VSTS builds

8e3d1f4

Fix isReleasedVersion check in AtomEnvironment

cd83486

Fix CommandInstaller tests

0d6b5d9

Don't change Atom app name on dev channel

0c364d0

Possible fix for FileRecoveryService test on Linux

ec2abbb

Re-enable Windows and Linux tests on VSTS

5634a64

daviwil added 2 commits July 6, 2018 17:03

Set timeout of 180 minutes on nightly build

e91030f

Remove queue setting in nightly build

0d0db81

daviwil mentioned this pull request Jul 9, 2018

Iteration Plan: July 9 - July 20, 2018 #17660

Closed

16 tasks

daviwil added 4 commits July 9, 2018 15:51

Write error to stderr if publishing release fails

49b9b9e

Add documentation for Atom Nightly build process

7b711cd

Minor tweaks to build documentation

fa326a0

Simplify atom-x64 nupkg path generation

bea3267

daviwil commented Jul 9, 2018

View reviewed changes

daviwil changed the title ~~[WIP] Implement RFC 002: Atom Nightly Releases~~ Implement RFC 002: Atom Nightly Releases Jul 9, 2018

maxbrunsfeld approved these changes Jul 9, 2018

View reviewed changes

daviwil added 2 commits July 10, 2018 12:55

Try possible fix for broken GitHub package tests

3046f68

Revert "Try possible fix for broken GitHub package tests"

3109958

This reverts commit 3046f68.

daviwil commented Jul 11, 2018

View reviewed changes

This was referenced Jul 11, 2018

Enable 32-bit Windows builds for Nightly channel #17668

Closed

Automatically generate release notes for Nightly releases #17669

Closed

Migrate Atom's update distribution to Electron's update.electronjs.org service #17670

Open

daviwil merged commit 972b11c into master Jul 11, 2018

daviwil deleted the dw-nightly-releases branch July 11, 2018 17:28

lee-dohm mentioned this pull request Jul 12, 2018

Don't delete the package-lock.json in /script/vsts #17677

Merged

daviwil mentioned this pull request Jul 12, 2018

Use a consistent app naming strategy across non-stable channels #17680

Merged

4 tasks

daviwil mentioned this pull request Jul 30, 2018

Add missing x64 build artifacts to appveyor.yml #17761

Merged

This was referenced Aug 6, 2018

Remove CircleCI configuration #17788

Merged

Migration To CircleCI 2.0 #17105

Closed

DeeDeeG mentioned this pull request Jul 10, 2020

Hacking on Atom Core: Update build requirements to be accurate atom/flight-manual.atom.io#630

Merged

confused-Techie mentioned this pull request Aug 29, 2022

Rebrand to Pulsar in docs pulsar-edit/pulsar#38

Closed

Implement RFC 002: Atom Nightly Releases #17538

Implement RFC 002: Atom Nightly Releases #17538

Uh oh!

Conversation

daviwil commented Jun 19, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of the Change

Alternate Designs

Why Should This Be In Core?

Benefits

Possible Drawbacks

Verification Process

Applicable Issues

Remaining Tasks

Failing Tests

Future Tasks

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jasonrudolph left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

simurai commented Jun 21, 2018

Uh oh!

thomasjo commented Jun 21, 2018

Uh oh!

maxbrunsfeld commented Jun 21, 2018

Uh oh!

daviwil commented Jun 21, 2018

Uh oh!

simurai commented Jun 22, 2018

Uh oh!

daviwil left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

daviwil commented Jul 9, 2018

Uh oh!

maxbrunsfeld left a comment

Choose a reason for hiding this comment

Uh oh!

daviwil left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

daviwil commented Jun 19, 2018 •

edited

Loading