From b057b77d285ab254a03f614e0beaeb875b79372c Mon Sep 17 00:00:00 2001
From: Victor Lin <13424970+victorlin@users.noreply.github.com>
Date: Tue, 4 Oct 2022 16:01:17 -0700
Subject: [PATCH 1/2] dev: Trim back the overgrown CI jobs

Same reasoning as @tsibley in https://github.com/nextstrain/cli/commit/fab709a2f45fc74afe2a15038e877e4dd58ae222:

Running on push _and_ PRs is often redundant.  For PRs, we really care
about the putative merge of the PR branch, and that's what "on:
pull_request" tests.  We typically do not need push-level CI results for
PRs.  On the other hand, CI results for every push to master are nice to
have both as a safety backstop and for the linear chain of CI history it
produces (e.g. to debug the impact of external changes on our CI).

The primary downside I see is that you can no longer push without
opening a PR just to see what CI says, but I think that's an acceptable
tradeoff, especially now that draft PRs are a thing.  To mitigate this
downside, "on: workflow_dispatch" allows CI to be manually dispatched
for a specific branch/tag/commit if you _really_ don't want to open even
a draft PR.

Trimming unnecessary CI jobs reduces the time to completion for CI runs
(good for the dev loop) and reduces organization-level job queuing,
which can negatively impact the workflows of other repos.

Co-authored-by: Thomas Sibley <tsibley@fredhutch.org>
---
 .github/workflows/ci.yml | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 0d19ecd63..e5dc83019 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -1,5 +1,10 @@
 name: CI
-on: [push, pull_request]
+on:
+  push:
+    branches:
+      - master
+  pull_request:
+  workflow_dispatch:
 jobs:
   test:
     if: github.repository == 'nextstrain/nextstrain.org'

From b741fc19d61fa84d48e8d6c71e76d89a1eeefb66 Mon Sep 17 00:00:00 2001
From: Victor Lin <13424970+victorlin@users.noreply.github.com>
Date: Tue, 4 Oct 2022 15:58:26 -0700
Subject: [PATCH 2/2] CI: Build Auspice client

It can be useful to test that a newer Auspice version builds properly in
the context of this project.
---
 .github/workflows/ci.yml | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index e5dc83019..7eb607c4a 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -33,6 +33,17 @@ jobs:
           name: logs
           path: test/server.log
 
+  build-auspice-client:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: actions/setup-node@v3
+        with:
+          node-version: '14'
+      - run: node --version
+      - run: npm ci
+      - run: node_modules/.bin/auspice build --verbose --extend auspice-client/customisations/config.json
+
   # XXX TODO: It'd be nice to avoid the rebuild on Heroku and instead deploy
   # the artifacts (source code + generated files + node_modules/) already built
   # above.  This would dramatically reduce deploy times and move us closer to
@@ -47,8 +58,8 @@ jobs:
       && github.event_name == 'push'
       && github.ref == 'refs/heads/master'
 
-    # Wait for "test" job above to pass.
-    needs: test
+    # Wait for other jobs above to pass.
+    needs: [test, build-auspice-client]
 
     # Only one "deploy" job at a time.
     concurrency: deploy