ci: only integration test on manual dispatch (#28)

* integration testing is only useful after a new mf6 release
* remove schedule and push/pr triggers from integration.yml
* remove schedule and push develop triggers from release.yml

.github/workflows/integration.yml

@@ -1,16 +1,6 @@
 name: Integration testing
 on:
-  push:
-    paths-ignore:
-      - '**.md'
-  pull_request:
-    branches:
-      - master
-      - develop
-    paths-ignore:
-      - '**.md'
-  schedule:
-    - cron: '0 6 * * *' # run at 6 AM UTC every day
+  workflow_dispatch:
 jobs:
   test_modflow:
     name: MODFLOW 6 integration tests

.github/workflows/release.yml

@@ -1,11 +1,11 @@
 name: Release MODFLOW executables
 on:
-  schedule:
-    - cron: '0 3 * * 3' # run at 3 AM UTC every Wednesday
   push:
     branches:
       - master
-      - develop
+  pull_request:
+    branches:
+      - master
   workflow_dispatch:
 env:
   DIST: dist

DEVELOPER.md

@@ -5,7 +5,6 @@ This document provides guidance for using this repository to release USGS execut
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 
-
 - [Overview](#overview)
 - [Triggering a release](#triggering-a-release)
   - [GitHub UI](#github-ui)
@@ -22,17 +21,16 @@ This repo is configured to allow manually triggering releases, independent of ch
 The `.github/workflows/release.yml` workflow is triggered on the following [events](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows):
 
 - `push` to `master`
-- `pull_request` to any branch
 - `workflow_dispatch`
 
-If the triggering event is `push` or `pull_request`, metadata is updated, binaries are built and uploaded as artifacts, and the workflow ends.
+If the triggering event is `push`, metadata is updated, binaries are built and uploaded as artifacts, and the workflow ends. This tests whether programs can be built by pymake.
+
+If the triggering event is `workflow_dispatch`:
 
-If the triggering event is a `workflow_dispatch`:
 - Metadata is updated. If changes are detected to any of the program versions or timestamps, a draft PR is opened against the `master` branch to update the table in `README.md`.
 - Binaries are built and uploaded as artifacts
 - A release is created, incrementing the version number.
 
-
 **Note**: the release is currently published immediately, but could be changed to a draft by updating the `draft` input on `ncipollo/release-action` in `.github/workflows/release.yml`.
 
 **Note**: version numbers don't currently follow semantic versioning conventions, but simply increment an integer for each release.
@@ -41,26 +39,28 @@ If the triggering event is a `workflow_dispatch`:
 
 The `workflow_dispatch` event is GitHub's mechanism for manually triggering workflows. This can be accomplished from the Actions tab in the GitHub UI, or via the [GitHub CLI](https://cli.github.com/manual/gh_workflow_run).
 
+First, trigger the `integration.yml` workflow to build mf6 with pymake and run it against the mf6 autotest suite. If tests pass, trigger the `release.yml` workflow to make the release.
+
 ### GitHub UI
 
-Navigate to the Actions tab of this repository. Select the release workflow. A `Run workflow` button should be visible in an alert at the top of the list of workflow runs. Click the `Run workflow` button, selecting the `master` branch. 
+Navigate to the Actions tab of this repository. Select a workflow. A `Run workflow` button should be visible in an alert at the top of the list of workflow runs. Click the `Run workflow` button, selecting the `master` branch. 
 
 ### GitHub CLI
 
 Install and configure the [GitHub CLI](https://cli.github.com/manual/) if needed. Then the following command can be run from the root of your local clone of the repository:
 
 ```shell
-gh workflow run release.yml
+gh workflow run <workflow>.yml
 ```
 
-On the first run, the CLI will prompt to choose whether the run should be triggered on your fork of the repository or on the upstream version. This decision is stored for subsequent runs &mdash; to override it later, use the `--repo` (short `-R`) option to specify the repository. For instance, if you initially selected your fork but would like to trigger a release on the main repository:
+On the first run, the CLI will prompt to choose whether the run should be triggered on your fork of the repository or on the upstream version. This decision is stored for subsequent runs &mdash; to override it later, use the `--repo` (short `-R`) option to specify the repository. For instance, if you initially selected your fork but would like to trigger on the main repository:
 
 ```shell
-gh workflow run release.yml -R MODFLOW-USGS/executables
+gh workflow run <workflow>.yml -R MODFLOW-USGS/executables
 ```
 
-**Note:** by default, workflow runs are associated with the repository's default branch. If the repo's default branch is `develop` (as is currently the case for `MODFLOW-USGS/executables`, you will need to use the `--ref` (short `-r`) option to specify the `master` branch when triggering a release from the CLI. For instance:
+**Note:** by default, workflow runs are associated with the repository's default branch. If the repo's default branch is `develop` (as is currently the case for `MODFLOW-USGS/executables`, you will need to use the `--ref` (short `-r`) option to specify the `master` branch when triggering from the CLI. For instance:
 
 ```shell
-gh workflow run release.yml -R MODFLOW-USGS/executables -r master
+gh workflow run <workflow>.yml -R MODFLOW-USGS/executables -r master
 ```