fix: use api endpoint for snapshots data (#110)

* fix: use api endpoint for snapshots data

Fixes #109.

* chore(ci): use built binary in test-action

Previously, we had a run of the action in the `test` job that used the
built binary (`no-install`), then we had a run of the action in
`test-action` (per os) that installed the latest release.

The benefit here was that the run in `test` exercised a built binary in
the context of the action, and the runs `test-action` exercised the
install step on each os. The downside is that if there is a problem with
the currently-released version (as there is right now), the
`test-action` runs will fail. Since we have strict status checks on PRs,
this makes it difficult to address that latest release.

This commit addresses the downside while losing that upside: it makes
the installation steps become untested. I think that's acceptable
because the bulk of the logic is provided by a 3rd-party action
(`pbrisbin/setup-tool-action`) which has its own test suite. Querying
for "latest" is the only logic truly becoming untested (for now).

* Revert "chore(ci): use built binary in test-action"

This reverts commit dc75a78.

* fix(ci): test installation only in test-action

Running SLED in the context of an action is already tested as a step in
the `test` job. `test-action` exists to test the (os-specific)
installation steps, so it installs the latest release. Sometimes (as is
the case now) there is a problem with that release which can cause
`test-action` to fail. This can make it hard to merge the PR that is
fixing things, since that status is required.

By adding a `run` input and not actually running the tool in
`test-action`, we can avoid this scenario by making the test only test
what it cares about, and so be more robust to false failures like this.

Author: pbrisbin

.github/workflows/ci.yml

@@ -15,6 +15,11 @@ jobs:
     steps:
       - uses: actions/checkout@v5
       - uses: freckle/stack-action@v5
+
+      # NOTE: This step tests execution in the context of an action, and is here
+      # so that it uses the branch-built binary. The test-action matrix exists
+      # separately to test the _installation_ portion of the action only, which
+      # is affected by operating system.
       - uses: ./
         with:
           arguments: --format gha --path test/examples/lts-18.18.yaml --no-exit
@@ -36,7 +41,8 @@ jobs:
       - uses: actions/checkout@v5
       - uses: ./
         with:
-          arguments: --path test/examples/lts-18.18.yaml --no-exit
+          run: false
+      - run: stack-lint-extra-deps --version
 
   nix:
     strategy:

action.yml

@@ -18,6 +18,12 @@ inputs:
       to be installed and on PATH already.
     required: false
     default: false
+  run:
+    description: |
+      Whether to run the tool or not. This is mostly useful for testing the
+      install portion of the action. Default is `true`.
+    required: false
+    default: true
   github-token:
     description: |
       GitHub token for authenticating with GitHub API (to determine release
@@ -59,7 +65,8 @@ runs:
         os-darwin: osx
         arch-x64: x86_64
 
-    - shell: bash
+    - if: ${{ inputs.run == 'true' }}
+      shell: bash
       run: |
         ${{inputs.executable}} ${{ inputs.arguments }}
       env:

src/SLED/Stackage/Snapshots.hs

@@ -62,7 +62,7 @@ getSnapshotsPage
 getSnapshotsPage page = liftIO $ try $ do
   req <-
     parseRequestThrow
-      $ "http://www.stackage.org/snapshots?page="
+      $ "https://www.stackage.org/api/v1/snapshots?page="
       <> show page
   resp <- httpJSON req
   pure $ getResponseBody resp