+#page-track-dashboard+  %nav.track-nav+    .lg-container.container+      = link_to "<-", tracks_path, class: "back"+      = image_tag(@track.icon_url, class: 'c-track-icon')+      .title= @track.title+      .tabs+        = link_to "#", class: 'selected' do+          Overview++        = link_to track_concepts_path(@track) do+          Concepts++        = link_to "#" do+          Exercises++  %header.track-header+    .lg-container.container+      = image_tag(@track.icon_url, class: 'c-track-icon')+      .info+        %h1= @track.title+        .joined Joined on #{format_date(@user_track.created_at)}+      .progress-bar++  %article+    .lg-container.container+      .lhs+      .rhs+        %section.contributors+          %header+            %h2 Contributors+            .count 123+          .showcase+            = link_to "#" do+              .img{ style: "background-image:url(https://avatars3.githubusercontent.com/u/135246?s=460&u=733b8575c8f0dbb5a52840c3efb2480b166c897a&v=4)" }+              .name Erik Schierboom+              .reputation+                = reputation_icon(color: "#8480A0")+                123+            = link_to "#" do+              .img{ style: "background-image:url(https://avatars2.githubusercontent.com/u/17816791?s=460&u=75b8876b2ec4d897e946888493a7fc7b7d97ec55&v=4)" }+              .name Rob Keim+              .reputation+                = reputation_icon(color: "#8480A0")+                456+          .faces+            = link_to "", "#", class: 'face', style: "background-image:url(https://avatars3.githubusercontent.com/u/2716614?s=460&u=7403dc7f80ccfd983705a1637fac1b12d2dcbad2&v=4)"+            = link_to "", "#", class: 'face', style: "background-image:url(https://avatars1.githubusercontent.com/u/20866761?s=400&u=9444c34f830fe94f2b68995646ed405a65911a91&v=4)"+            = link_to "", "#", class: 'face', style: "background-image:url(https://avatars3.githubusercontent.com/u/6624571?s=400&u=ca3801c9d18d8aa124738c8e8db470cbe5fd5814&v=4)"+            = link_to "", "#", class: 'face', style: "background-image:url(https://avatars2.githubusercontent.com/u/7852553?s=400&u=6227e3aeff0e649cce5483fca11deb3cc6481319&v=4)"+            = link_to "", "#", class: 'face', style: "background-image:url(https://avatars2.githubusercontent.com/u/281700?s=400&v=4)"+            = link_to "", "#", class: 'face', style: "background-image:url(https://avatars0.githubusercontent.com/u/6251883?s=400&u=1111c5251e1c1bbf6b45790b6ffa4a919c502bd6&v=4)"+            = link_to "", "#", class: 'face', style: "background-image:url(https://avatars2.githubusercontent.com/u/1964376?s=400&u=591370994dd91ec3d5f2a345252a653406858be0&v=4)"+            = link_to "", "#", class: 'face', style: "background-image:url(https://avatars2.githubusercontent.com/u/365425?s=400&v=4)"+            = link_to "See all", "#", class: "all"+          .cta+            %h3 We 💙 our contributors

+#page-track-dashboard+  %nav.track-nav+    .lg-container.container+      = link_to "<-", tracks_path, class: "back"+      = image_tag(@track.icon_url, class: 'c-track-icon')+      .title= @track.title+      .tabs+        = link_to "#", class: 'selected' do+          Overview++        = link_to track_concepts_path(@track) do+          Concepts++        = link_to "#" do+          Exercises++  %header.track-header+    .lg-container.container+      = image_tag(@track.icon_url, class: 'c-track-icon')

+#page-track-dashboard+  %nav.track-nav+    .lg-container.container+      = link_to "<-", tracks_path, class: "back"+      = image_tag(@track.icon_url, class: 'c-track-icon')+      .title= @track.title+      .tabs+        = link_to "#", class: 'selected' do+          Overview++        = link_to track_concepts_path(@track) do+          Concepts++        = link_to "#" do+          Exercises++  %header.track-header+    .lg-container.container+      = image_tag(@track.icon_url, class: 'c-track-icon')+      .info+        %h1= @track.title+        .joined Joined on #{format_date(@user_track.created_at)}

+#page-track-dashboard+  %nav.track-nav+    .lg-container.container+      = link_to "<-", tracks_path, class: "back"

 def authenticated_index     @tracks_data = SerializeTracks.(tracks, current_user)   end -  def authenticated_show+  def show     @user_track = UserTrack.for(current_user, @track)+    render "tracks/show/joined"

 linters:+  InlineStyles:+    enabled: false

+# Workflow templates++The content in this folder doesn't _necessarily_ belong in this repository, but we don't have a great place to put it that allows for good discoverability. The GitHub Actions workflows in this folder can be adapted to work with any CI, because the base structure will remain the same.++Example implementation of these workflow files [can be found in `exercism/javascript`][git-javascript].++## **HELP**: this looks like _a lot_ of work :sweat:++The rest of the document is really to explain what's going on in the workflows. If you're in a hurry, and you really want to drop `.travis.yml`, but you can't invest right now in making the PR scripts are optimized, scroll down to the **~10 minute guide** on [**Migrating from Travis**](#migrating-from-travis).++## Track CI actions++The recommended actions are as follows:++1. [`configlet` linting][git-configlet] in order to check `config.json`+2. check for stubs+3. check for documentation (`v3` requires new files; this might move to `configlet`)+4. lint the exercises using a "maintainers" configuration

+# This workflow will do a clean install of node dependencies and run tests across different versions+#+# Replace <track> with the track name+# Replace <image-name> with an image to run the jobs on+# Replace <action to setup tooling> with a github action to setup tooling on the image+# Replace <install dependencies> with a cli command to install the dependencies+# Replace <code-extensions> with file extensions that should trigger the workflow+#+# Requires scripts:+# - scripts/ci-check+# - scripts/ci++name: <track> / master++on:+  push:+    branches: [master]+  workflow_dispatch:++jobs:+  precheck:+    runs-on: <image-name>++    steps:+      - uses: actions/checkout@v2+      - name: Use <setup tooling>+        uses: <action to setup tooling>+        with:+          # here, use the LTS/stable version of the track's tooling+          # node-version: 12.x++      - name: Install project dependencies+        run: <install dependencies>++      - name: Run exercism/<track> ci pre-check (checks config, lint code) for all exercises+        run: scripts/ci-check++  ci:+    runs-on: <image-name>

+# Workflow templates++The content in this folder doesn't _necessarily_ belong in this repository, but we don't have a great place to put it that allows for good discoverability. The GitHub Actions workflows in this folder can be adapted to work with any CI, because the base structure will remain the same.++Example implementation of these workflow files [can be found in `exercism/javascript`][git-javascript].++## **HELP**: this looks like _a lot_ of work :sweat:++The rest of the document is really to explain what's going on in the workflows. If you're in a hurry, and you really want to drop `.travis.yml`, but you can't invest right now in making the PR scripts are optimized, scroll down to the **~10 minute guide** on [**Migrating from Travis**](#migrating-from-travis).++## Track CI actions++The recommended actions are as follows:++1. [`configlet` linting][git-configlet] in order to check `config.json`+2. check for stubs+3. check for documentation (`v3` requires new files; this might move to `configlet`)+4. lint the exercises using a "maintainers" configuration+5. test the exercises using the example/examplar files (can include build step)++There can be track-specific actions, for example:++1. check the [integrity][wiki-integrity] of the exercise configurations+2. check the formatting of the exercise files++And perhaps you'd want more Quality Of Life checks, such as:++1. ensure CONTRIBUTING exists+2. ensure there is a sane lockfile for dependencies+3. ensure links inside markdown files are valid+4. ...++## Recommendations++For each action think about how often it should run.++- The `configlet` linting is something that's so important (because a track can break if the `config.json` breaks), that it probably should run, always, **but** only needs to run once per commit.+- The existence or integrity of files only needs to run once per commit.+- If a track is supposed to run under multiple runtime-versions or compiler-versions, building/testing exercises should be ran against each supported version+- PRs _probably_ only need to run actions on files _added_ or _changed_, but since a file can influence an exercise, it's safer to run the actions for the _exercise_, if one of its files changes.++It can be very helpful to make the actions that should run, available locally as well. This means that the scripts that do the actual work are also manually runnable. **Do not inline** the action inside the workflow files. For example, checking for stubs can be completely bashed out inside the workflow file, but the recommendation here is to create a new executable script `scripts/ci-check` instead.++> "But the command is very short, e.g. `eslint . --ext ts --ext tsx`".+>+> When this command needs to be updated, it now needs to update in all the places in the documentation, the workflow files, ánd in the _minds of the maintainers_. Extracting this to a script resolves all that. Reading a workflow file can also be **very** daunting.++### PR exercises changed++The `scripts/pr` and `scripts/pr-check` scripts are ran with arguments: each file that has been changed or added in this PR. For example, if `two-fer` has been updated, a call might look like this:++```bash+scripts/pr exercises/two-fer/README.md exercises/two-fer/.meta/example.ext+```++It's recommended to run any actions against the changed _exercise_ and not the changed _file_. This is because changing a file is likely to trigger changes for the entire exercise (think: configuration, packages).++> **Not ready?** / **Complex?**+>+> Before implementing this optimization, it may be ignored! The migration guide hints at adding at a later stage. If the input arguments are ignored, all the checks are running on all the exercises. **This is perfectly fine**. It will just take longer.++### Integrity++If the track has a single "top-level" dependency file and/or other configuration files, add an [integrity][wiki-integrity] step (to exist alongside a `scripts/sync` or `bin/sync`, which would copy all configuration files to all exercises) that ensures the top-level/base files are the same as the one copied to the exercise directories. Now dependencies can be updates, synced across the repository, and ensures that all exercises have the same configuration.++A common way to accomplish this is to use a checksum. Ubuntu (and various other Linux distributions) comes with a tool called `sha1sum`, but using _whichever_ method to hash or reduce the configuration file (md5, sha1, crc32) to a checksum value, would work:++```bash+$ sha1sum README.md+cd58091c5043bf21f00d39ff1740d8b2976deeff *README.md+```++### Security++If the track uses additional workflows that require access to the GitHub token or other secrets, it's best practice to pin **all** actions used in the workflow to a specific commit. See [GitHub's security hardening guide][github-actions-security] for details.++For example:++```diff+- uses: julia-actions/setup-julia@v1++ uses: julia-actions/setup-julia@d26d1111976eae5f00db04f0515ab744ec9cd79e # 1.3.1+```++If the tooling has lockfiles for dependency management, consider checking it into the repository and use a "frozen lockfile" inside the workflow files. For example: `npm ci`, `yarn install --frozen-lockfile` and `bundle install --frozen`. This ensures that the lockfile is up-to-date when changing dependencies and prevents malicious packages to come in.++## Templates++In this directory at minimum there are the following templates:++- `configlet.yml`: This workflow will do a fetch the latest configlet binary and lint this repository. Run on every commit. For PRs, runs on the actual commit and a "after merge" tree.+- `ci.yml`: This workflow **only runs on `master`**, once on each commit.+  1. Run a 'pre-check' command (check for stubs, lint, docs, etc.) for all exercises+  2. Run a 'ci' command (build and test) for multiple versions, for all exercises+- `pr.ci.yml`: This workflow **only runs on PRs**, once on each commit.+  1. Run a 'pre-check' command (check for stubs, lint, docs, etc.) for changed files+  2. Run a 'ci' command (build and test) for multiple versions, for changed exercises++The non-pr workflows can also be triggered via [`workflow_dispatch`][github-workflow-dispatch].++Each file has listed at the top which "scripts" should be available. If you want these to be binaries, replace `scripts/xxx` with `bin/xxx`. Some tooling will _require_ binaries to be inside a `bin` folder.++- `scripts/ci`: a script that should build and test all exercises using the example solutions against the tests+- `scripts/ci-check`: a script that should lint all exercises, and optionally check for stubs, configuration integrity, and more+- `scripts/pr`: same as `scripts/ci`, but should only run exercises resolved from the paths given as input+- `scripts/pr-check`: same as `scripts/ci-check`, but should only run for files or exercises resolved from the paths given as input++## Migrating from Travis++Here is an example `.travis.yml` (taken from the `elm` track):++```yml+sudo: false+language: node_js+node_js:+  - lts/*+script:+  - bin/fetch-configlet+  - bin/configlet lint .+  - bin/build.sh+```++In order to convert this quickly to GitHub Actions, take the following steps:++### Determine the template variables++| variable                    | value                                |+| --------------------------- | ------------------------------------ |+| `<track>`                   | `elm`                                |+| `<image-name>`              | `ubuntu-latest`                      |+| `<action to setup tooling>` | `actions/setup-node@v1`              |+| `<install dependencies>`    | `npm ci` (happens inside `build.sh`) |+| `<code-extensions>`         | `.elm`                               |++> Found the setup action via [this search](https://github.com/actions/?q=setup+node&type=&language=).+> Found the image name by looking at [default distribution for Travis](https://blog.travis-ci.com/2019-04-15-xenial-default-build-environment).++### Determine the steps++- `bin/fetch-configlet`: don't need this anymore when using `configlet.yml` workflow+- `bin/configlet lint .`: don't need this anymore when using `configlet.yml` workflow+- `bin/build.sh`: single script that does everything++### Prepare the "scripts"++This track uses the `bin` folder, so inside the `bin` folder, create the following files:++```bash+# bin/pr+bin/build.sh+```++```bash+# bin/pr-check+echo "No checks yet"+```++```bash+# bin/ci+bin/build.sh+```++```bash+# bin/ci-check+echo "No checks yet"+```++Creating these as _separate_ binaries will allow for optimisation later. No need to in-line anything right now.++### Fill in the templates++Here is the diff for `workflows/ci.yml`.++```diff+# # .github/workflows/ci.yml++  # This workflow will do a clean install of node dependencies and run tests across different versions+  #+- # Replace <track> with the track name+- # Replace <image-name> with an image to run the jobs on+- # Replace <action to setup tooling> with a github action to setup tooling on the image+- # Replace <install dependencies> with a cli command to install the dependencies+- # Replace <code-extensions> with file extensions that should trigger the workflow+- #+- # Find Github Actions to setup tooling here:+- # - https://github.com/actions/?q=setup&type=&language=+- # - https://github.com/actions/starter-workflows/tree/main/ci+- # - https://github.com/marketplace?type=actions&query=setup+- #+  # Requires scripts:+- # - scripts/ci-check+- # - scripts/ci++ # - bin/ci-check++ # - bin/ci++- name: <track> / master++ name: elm / master++  on:+    push:+      branches: [master]

+# This workflow will do a clean install of the dependencies and run tests across different versions+#+# Replace <track> with the track name+# Replace <image-name> with an image to run the jobs on+# Replace <action to setup tooling> with a github action to setup tooling on the image+# Replace <install dependencies> with a cli command to install the dependencies+# Replace <code-extensions> with file extensions that should trigger the workflow+#+# Find Github Actions to setup tooling here:+# - https://github.com/actions/?q=setup&type=&language=+# - https://github.com/actions/starter-workflows/tree/main/ci+# - https://github.com/marketplace?type=actions&query=setup+#+# Requires scripts:+# - scripts/ci-check+# - scripts/ci++name: <track> / master

+# This workflow will do a clean install of the dependencies and run tests across different versions+#+# Replace <track> with the track name+# Replace <image-name> with an image to run the jobs on+# Replace <action to setup tooling> with a github action to setup tooling on the image+# Replace <install dependencies> with a cli command to install the dependencies+# Replace <code-extensions> with file extensions that should trigger the workflow+#+# Find Github Actions to setup tooling here:+# - https://github.com/actions/?q=setup&type=&language=+# - https://github.com/actions/starter-workflows/tree/main/ci+# - https://github.com/marketplace?type=actions&query=setup+#+# Requires scripts:+# - scripts/ci-check+# - scripts/ci++name: <track> / master++on:+  push:+    branches: [master]

+# Workflow templates++The content in this folder doesn't _necessarily_ belong in this repository, but we don't have a great place to put it that allows for good discoverability. The GitHub Actions workflows in this folder can be adapted to work with any CI, because the base structure will remain the same.++Example implementation of these workflow files [can be found in `exercism/javascript`][git-javascript].++## **HELP**: this looks like _a lot_ of work :sweat:++The rest of the document is really to explain what's going on in the workflows. If you're in a hurry, and you really want to drop `.travis.yml`, but you can't invest right now in making the PR scripts are optimized, scroll down to the **~10 minute guide** on [**Migrating from Travis**](#migrating-from-travis).++## Track CI actions++The recommended actions are as follows:++1. [`configlet` linting][git-configlet] in order to check `config.json`+2. check for stubs+3. check for documentation (`v3` requires new files; this might move to `configlet`)+4. lint the exercises using a "maintainers" configuration+5. test the exercises using the example/examplar files (can include build step)++There can be track-specific actions, for example:++1. check the [integrity][wiki-integrity] of the exercise configurations+2. check the formatting of the exercise files++And perhaps you'd want more Quality Of Life checks, such as:++1. ensure CONTRIBUTING exists+2. ensure there is a sane lockfile for dependencies+3. ensure links inside markdown files are valid+4. ...++## Recommendations++For each action think about how often it should run.++- The `configlet` linting is something that's so important (because a track can break if the `config.json` breaks), that it probably should run, always, **but** only needs to run once per commit.+- The existence or integrity of files only needs to run once per commit.+- If a track is supposed to run under multiple runtime-versions or compiler-versions, building/testing exercises should be ran against each supported version+- PRs _probably_ only need to run actions on files _added_ or _changed_, but since a file can influence an exercise, it's safer to run the actions for the _exercise_, if one of its files changes.++It can be very helpful to make the actions that should run, available locally as well. This means that the scripts that do the actual work are also manually runnable. **Do not inline** the action inside the workflow files. For example, checking for stubs can be completely bashed out inside the workflow file, but the recommendation here is to create a new executable script `scripts/ci-check` instead.++> "But the command is very short, e.g. `eslint . --ext ts --ext tsx`".+>+> When this command needs to be updated, it now needs to update in all the places in the documentation, the workflow files, ánd in the _minds of the maintainers_. Extracting this to a script resolves all that. Reading a workflow file can also be **very** daunting.++### PR exercises changed++The `scripts/pr` and `scripts/pr-check` scripts are ran with arguments: each file that has been changed or added in this PR. For example, if `two-fer` has been updated, a call might look like this:++```bash+scripts/pr exercises/two-fer/README.md exercises/two-fer/.meta/example.ext+```++It's recommended to run any actions against the changed _exercise_ and not the changed _file_. This is because changing a file is likely to trigger changes for the entire exercise (think: configuration, packages).++> **Not ready?** / **Complex?**+>+> Before implementing this optimization, it may be ignored! The migration guide hints at adding at a later stage. If the input arguments are ignored, all the checks are running on all the exercises. **This is perfectly fine**. It will just take longer.++### Integrity++If the track has a single "top-level" dependency file and/or other configuration files, add an [integrity][wiki-integrity] step (to exist alongside a `scripts/sync` or `bin/sync`, which would copy all configuration files to all exercises) that ensures the top-level/base files are the same as the one copied to the exercise directories. Now dependencies can be updates, synced across the repository, and ensures that all exercises have the same configuration.++A common way to accomplish this is to use a checksum. Ubuntu (and various other Linux distributions) comes with a tool called `sha1sum`, but using _whichever_ method to hash or reduce the configuration file (md5, sha1, crc32) to a checksum value, would work:++```bash+$ sha1sum README.md+cd58091c5043bf21f00d39ff1740d8b2976deeff *README.md+```++### Security++If the track uses additional workflows that require access to the GitHub token or other secrets, it's best practice to pin **all** actions used in the workflow to a specific commit. See [GitHub's security hardening guide][github-actions-security] for details.++For example:++```diff+- uses: julia-actions/setup-julia@v1++ uses: julia-actions/setup-julia@d26d1111976eae5f00db04f0515ab744ec9cd79e # 1.3.1+```++If the tooling has lockfiles for dependency management, consider checking it into the repository and use a "frozen lockfile" inside the workflow files. For example: `npm ci`, `yarn install --frozen-lockfile` and `bundle install --frozen`. This ensures that the lockfile is up-to-date when changing dependencies and prevents malicious packages to come in.++## Templates++In this directory at minimum there are the following templates:++- `configlet.yml`: This workflow will do a fetch the latest configlet binary and lint this repository. Run on every commit. For PRs, runs on the actual commit and a "after merge" tree.+- `ci.yml`: This workflow **only runs on `master`**, once on each commit.

+# Workflow templates++The content in this folder doesn't _necessarily_ belong in this repository, but we don't have a great place to put it that allows for good discoverability. The GitHub Actions workflows in this folder can be adapted to work with any CI, because the base structure will remain the same.++Example implementation of these workflow files [can be found in `exercism/javascript`][git-javascript].++## **HELP**: this looks like _a lot_ of work :sweat:++The rest of the document is really to explain what's going on in the workflows. If you're in a hurry, and you really want to drop `.travis.yml`, but you can't invest right now in making the PR scripts are optimized, scroll down to the **~10 minute guide** on [**Migrating from Travis**](#migrating-from-travis).++## Track CI actions++The recommended actions are as follows:++1. [`configlet` linting][git-configlet] in order to check `config.json`+2. check for stubs+3. check for documentation (`v3` requires new files; this might move to `configlet`)+4. lint the exercises using a "maintainers" configuration+5. test the exercises using the example/examplar files (can include build step)++There can be track-specific actions, for example:++1. check the [integrity][wiki-integrity] of the exercise configurations+2. check the formatting of the exercise files++And perhaps you'd want more Quality Of Life checks, such as:++1. ensure CONTRIBUTING exists+2. ensure there is a sane lockfile for dependencies+3. ensure links inside markdown files are valid+4. ...++## Recommendations++For each action think about how often it should run.++- The `configlet` linting is something that's so important (because a track can break if the `config.json` breaks), that it probably should run, always, **but** only needs to run once per commit.+- The existence or integrity of files only needs to run once per commit.+- If a track is supposed to run under multiple runtime-versions or compiler-versions, building/testing exercises should be ran against each supported version+- PRs _probably_ only need to run actions on files _added_ or _changed_, but since a file can influence an exercise, it's safer to run the actions for the _exercise_, if one of its files changes.++It can be very helpful to make the actions that should run, available locally as well. This means that the scripts that do the actual work are also manually runnable. **Do not inline** the action inside the workflow files. For example, checking for stubs can be completely bashed out inside the workflow file, but the recommendation here is to create a new executable script `scripts/ci-check` instead.++> "But the command is very short, e.g. `eslint . --ext ts --ext tsx`".+>+> When this command needs to be updated, it now needs to update in all the places in the documentation, the workflow files, ánd in the _minds of the maintainers_. Extracting this to a script resolves all that. Reading a workflow file can also be **very** daunting.++### PR exercises changed++The `scripts/pr` and `scripts/pr-check` scripts are ran with arguments: each file that has been changed or added in this PR. For example, if `two-fer` has been updated, a call might look like this:++```bash+scripts/pr exercises/two-fer/README.md exercises/two-fer/.meta/example.ext+```++It's recommended to run any actions against the changed _exercise_ and not the changed _file_. This is because changing a file is likely to trigger changes for the entire exercise (think: configuration, packages).++> **Not ready?** / **Complex?**+>+> Before implementing this optimization, it may be ignored! The migration guide hints at adding at a later stage. If the input arguments are ignored, all the checks are running on all the exercises. **This is perfectly fine**. It will just take longer.++### Integrity++If the track has a single "top-level" dependency file and/or other configuration files, add an [integrity][wiki-integrity] step (to exist alongside a `scripts/sync` or `bin/sync`, which would copy all configuration files to all exercises) that ensures the top-level/base files are the same as the one copied to the exercise directories. Now dependencies can be updates, synced across the repository, and ensures that all exercises have the same configuration.++A common way to accomplish this is to use a checksum. Ubuntu (and various other Linux distributions) comes with a tool called `sha1sum`, but using _whichever_ method to hash or reduce the configuration file (md5, sha1, crc32) to a checksum value, would work:++```bash+$ sha1sum README.md+cd58091c5043bf21f00d39ff1740d8b2976deeff *README.md+```++### Security++If the track uses additional workflows that require access to the GitHub token or other secrets, it's best practice to pin **all** actions used in the workflow to a specific commit. See [GitHub's security hardening guide][github-actions-security] for details.++For example:++```diff+- uses: julia-actions/setup-julia@v1++ uses: julia-actions/setup-julia@d26d1111976eae5f00db04f0515ab744ec9cd79e # 1.3.1+```++If the tooling has lockfiles for dependency management, consider checking it into the repository and use a "frozen lockfile" inside the workflow files. For example: `npm ci`, `yarn install --frozen-lockfile` and `bundle install --frozen`. This ensures that the lockfile is up-to-date when changing dependencies and prevents malicious packages to come in.

+# Workflow templates++The content in this folder doesn't _necessarily_ belong in this repository, but we don't have a great place to put it that allows for good discoverability. The GitHub Actions workflows in this folder can be adapted to work with any CI, because the base structure will remain the same.++Example implementation of these workflow files [can be found in `exercism/javascript`][git-javascript].++## **HELP**: this looks like _a lot_ of work :sweat:++The rest of the document is really to explain what's going on in the workflows. If you're in a hurry, and you really want to drop `.travis.yml`, but you can't invest right now in making the PR scripts are optimized, scroll down to the **~10 minute guide** on [**Migrating from Travis**](#migrating-from-travis).++## Track CI actions++The recommended actions are as follows:++1. [`configlet` linting][git-configlet] in order to check `config.json`+2. check for stubs+3. check for documentation (`v3` requires new files; this might move to `configlet`)+4. lint the exercises using a "maintainers" configuration

            #:test-exercises            #:problems-p            #:full-build-           #:travis-build)+           #:ci-build)   (:documentation "xlisp-test  Script for running the tests for exercism exercises of the xlisp track. Used for integration testing on new and changed exercises. -See .travis.yml for how it's run.

            #:test-exercises            #:problems-p            #:full-build-           #:travis-build)+           #:ci-build)   (:documentation "xlisp-test  Script for running the tests for exercism exercises of the xlisp track. Used for integration testing on new and changed exercises. -See .travis.yml for how it's run.

+name: configlet-lint++on:+  push:+  pull_request:+    branches: [master]

            #:test-exercises            #:problems-p            #:full-build-           #:travis-build)+           #:ci-build)   (:documentation "xlisp-test  Script for running the tests for exercism exercises of the xlisp track. Used for integration testing on new and changed exercises. -See .travis.yml for how it's run.

+name: configlet-lint++on:+  push:+  pull_request:+    branches: [master]

+name: exercise-tests++on:+  push:+  pull_request:+    branches: [master]