This is a script for setting up continuous integration with an Atom project.

Add the following line to your project's .travis.yml file:

script: curl -sL https://git.io/fji1w | sh

Add the following lines to your project's appveyor.yml file:

install:
  - ps: Install-Product node $env:nodejs_version

test_script:
  - ps: (New-Object net.WebClient).DownloadString("https://git.io/JWdh6") | iex

Add one or both of the following steps to your project's workflow:

steps:
  - name:  Run package tests (macOS, Linux)
    if:    ${{ startsWith(matrix.os, 'macOS') || startsWith(matrix.os, 'Ubuntu') }}
    run:   curl -sL https://git.io/fji1w | sh
    shell: sh

  - name:  Run package tests (Windows)
    if:    ${{ startsWith(matrix.os, 'Windows') }}
    run:   (New-Object net.WebClient).DownloadString("https://git.io/JWdh6") | iex
    shell: powershell

A more complete workflow example can be found here.

It's fundamentally the same as atom/ci, with the following differences:

1. GitHub's release pages are consulted directly for downloads.
   This is a tad bit slower than downloading from atom.io, but it means sudden changes to their infrastructure won't break your build.

2. Arbitrary release channels (dev, nightly) are unsupported.
   Only stable and beta releases of Atom can be tested against. However, users can set $ATOM_RELEASE in their environment to build against an arbitrary Atom version:

   env:
     - ATOM_CHANNEL=stable   # Latest stable release (default)
     - ATOM_RELEASE=v1.34.0  # Override ATOM_CHANNEL and test specific version

3. lint or test scripts defined in package.json are used, if possible.
   If your package manifest defines a lint or test script, the POSIX version of the CI script will call those instead. For example:

   {
   	"scripts": {
   		"lint": "npx eslint --ext mjs,js ./lib/ ./tools",
   		"test": "atom -t ./specs"
   	}
   }

   If you don't specify a script, the usual defaults assumed by atom/ci are attempted instead:

   # Linting
   DIRS="./lib ./src ./spec ./test"
   npx coffeelint $DIRS
   npx eslint $DIRS
   npx tslint $DIRS
   
   # Testing
   DIRS="./spec ./specs ./test ./tests"
   atom --test $DIRS

   Note that only linters listed in devDependencies will be run, and missing directories will be skipped. However, at least one test directory must be included, or else the build will fail.

If you're running builds on Ubuntu, be forewarned that Atom's beta channel may give dpkg an archive it can't unpack due to a bug with older versions of dpkg. The solution is to run builds on Xenial instead of Trusty, which requires that you include libgconf2-4 as a dependency:

@@ .travis.yml @@
 addons:
   apt:
     packages:
     - build-essential
     - fakeroot
     - git
+    - libgconf2-4
     - libsecret-1-dev

• Support the atom-mocha executable, once it can be run globally
• Support an environment variable for specifying package's root directory
• Test PowerShell version on Linux
• Use GitHub's [command] syntax for echoing external commands
• Make POSIX version's $PATH tampering consistent with PowerShell's
• Document and dogfood AppVeyor usage

On July 6th 2019 AEST, Atom's CI script suddenly broke. The culprit was botched handling of a curl(1) request which included an Accept header:

$ curl -L "https://atom.io/download/mac?channel=${ATOM_CHANNEL}" \
	-H 'Accept: application/octet-stream' \
	-o "atom.zip"
######################################################################## 100.0%
curl: (22) The requested URL returned error: 406 Not Acceptable

Following the URL simply lead to Atom's releases page on GitHub. I was unsure what the link usually pointed to, but having this break the builds of each of my projects was certainly not the intended outcome.

Since I'm blocked from the @atom org on GitHub, I was unable to report this or submit a pull-request. So I took things into my own hands, as usual.