profile
viewpoint

exercism/cli 932

A Go based command line tool for exercism.io.

exercism/c 151

Exercism exercises in C.

exercism/clojure 97

Exercism exercises in Clojure.

exercism/bash 74

Exercism exercises in Bash.

exercism/automated-analysis 26

An overview space for Automated Analysis on Exercism

exercism/cfml 11

Exercism exercises in CFML.

exercism/arkov 8

A markov chain generator to help create interesting seed data.

exercism/automated-tests 8

An overview space for Automated Testing on Exercism

exercism/blog 8

Exercism's blog content

pull request commentexercism/ruby

Add Github Actions workflows

I plan to validate this and workflows from other tracks using the nektos/act project. However, it's late in my timezone, so I'll do so in the morning.

I was aware that it was getting close to midnight thirty for you… no worries.

kotp

comment created time in 4 minutes

push eventexercism/elm

Corey McCandless

commit sha eaef2bdd84e803c796298271d8c7d28de72ba238

Change status badge to GitHub Actions

view details

push time in 18 minutes

PR merged exercism/elm

Change status badge to GitHub Actions
+1 -1

0 comment

1 changed file

cmccandless

pr closed time in 18 minutes

PullRequestReviewEvent

push eventexercism/elm

Matthieu Pizenberg

commit sha 0e985db93b723052c6f237ec0b093d4a388ad022

Update dependencies (#307) * Update dependencies * Update elm-format version in build.sh * Run tests from the build/ directory

view details

push time in 23 minutes

delete branch exercism/elm

delete branch : deps

delete time in 23 minutes

PR merged exercism/elm

Update dependencies
+78 -189

2 comments

3 changed files

mpizenberg

pr closed time in 23 minutes

pull request commentexercism/ruby

Add Github Actions workflows

I plan to validate this and workflows from other tracks using the nektos/act project. However, it's late in my timezone, so I'll do so in the morning.

kotp

comment created time in 36 minutes

PullRequestReviewEvent

push eventexercism/bash-test-runner

Erik Schierboom

commit sha 028b36b828a243b2827c9659f8ad29fb40a87c64

Add maintainers-admin team as codeowner

view details

push time in 41 minutes

PR merged exercism/bash-test-runner

Add exercism/maintainers-admin team as codeowner

The tooling is essential to the functioning of v3. To help ensure that any changes work well with the v3 website, the exercism/maintainers-admin team is added as a codeowner.

See https://github.com/exercism/exercism/issues/5400

+1 -0

0 comment

1 changed file

ErikSchierboom

pr closed time in 41 minutes

pull request commentexercism/ruby

Add Github Actions workflows

Getting:

The workflow is not valid. .github/workflows/exercise-tests.yml (Line: 55, Col: 21): Unrecognized named-value: 'test-arch'. Located at position 1 within expression: test-arch

for the action @cmccandless

kotp

comment created time in 42 minutes

pull request commentexercism/ruby

Add Github Actions workflows

These workflows will not run unless they already exist in the target branch because they are from a fork.

I provided #1048 because I was curious if the GHA would work if they were directly on the repository, rather than on a fork, including the genesis commit for the configuration. Can you look at it and verify?

cmccandless

comment created time in 44 minutes

PR opened exercism/ruby

Add Github Actions workflows

This is a solution to testing #1047

Applied the patch so that it could be on this repository directly.

+80 -0

0 comment

3 changed files

pr created time in an hour

create barnchexercism/ruby

branch : pr_1047_proxy

created branch time in an hour

PullRequestReviewEvent

Pull request review commentexercism/v3-website

Add header and contributors box to track page

+#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

Suggest to wrap that 💙 inside e.g. a span or i, and add aria-label.

iHiD

comment created time in an hour

Pull request review commentexercism/v3-website

Add header and contributors box to track page

+#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')

Probably want to add the alt

iHiD

comment created time in an hour

Pull request review commentexercism/v3-website

Add header and contributors box to track page

+#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)}

Probably want to wrap this in a <time> element.

Joined on <time datetime="<%= @user_track.created_at.iso8601 %>">
  <%= format_date(@user_track.created_at) %>
</time>
iHiD

comment created time in an hour

Pull request review commentexercism/v3-website

Add header and contributors box to track page

+#page-track-dashboard+  %nav.track-nav+    .lg-container.container+      = link_to "<-", tracks_path, class: "back"
      = link_to "<-", tracks_path, class: "back", 'aria-label': 'Back to all tracks'
iHiD

comment created time in an hour

Pull request review commentexercism/v3-website

Add header and contributors box to track page

 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"

This might be right, but for a reader it's very confusing. Shouldn't this be inside the if?

iHiD

comment created time in an hour

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentexercism/ruby

Add Github Actions workflows

Did you want to prepare the expected PR? So when this comes in, we can then verify and bring the second one in as well?

cmccandless

comment created time in an hour

issue commentexercism/swift

Moving from Travis to GitHub Actions

You can also tag @exercism/github-actions for assistance in related PRs.

ErikSchierboom

comment created time in an hour

PullRequestReviewEvent

Pull request review commentexercism/v3-website

Add header and contributors box to track page

 linters:+  InlineStyles:+    enabled: false

lol ❤️

iHiD

comment created time in an hour

PullRequestReviewEvent

PR opened exercism/elm

Change status badge to GitHub Actions
+1 -1

0 comment

1 changed file

pr created time in an hour

issue openedexercism/v3-website

Add StrictMode to make errors show up earlier in development

See this.

At the root (I think that's the "react component render helper"), wrap whatever we're rendering in <React.StrictMode>.

created time in an hour

fork cmccandless/elm

Exercism exercises in Elm.

http://exercism.io/languages/elm

fork in an hour

issue commentexercism/v3-website

Noisy yarn output

It's an out-of-band warning -- so whomever fixes this, don't fix it by "hiding" the log. Fix the actual warning.

iHiD

comment created time in an hour

PR opened exercism/ruby

Add Github Actions workflows

Resolves #1045

These workflows will not run unless they already exist in the target branch because they are from a fork. Once this is merged and verified, all references to Travis CI (.travis.yml, badge in README, etc) should be removed in an additional PR.

+80 -0

0 comment

3 changed files

pr created time in an hour

pull request commentexercism/problem-specifications

Add workflow recommendations and templates

Thank you everyone who read along, gave suggestions, or/and pinged me on Slack.

Thanks @SaschaMann for your early help and thanks @iHiD for fixing the 5:00 English.

Y'all can now PR changes

SleeplessByte

comment created time in an hour

push eventexercism/problem-specifications

Derk-Jan Karrenbeld

commit sha efda1e39a7ae513c21b4f8690055fb866f3b7d31

Add workflow recommendations and templates (#1722) Adds a document that explains how to set up Continuous Integration (CI) workflows for an Exercism Language Track using GitHub Actions (GHA). It provides best practices and examples for you to use to make your own fast, reliable and robust CI workflows. Additionally, it provides GHA workflows. The GHA workflows can be adapted to work with any CI, track, or project, because the base structure will remain the same.

view details

push time in an hour

delete branch exercism/problem-specifications

delete branch : chore/gha-templates

delete time in an hour

PR merged exercism/problem-specifications

Reviewers
Add workflow recommendations and templates CI documentation

Based on all the feedback I got from @SaschaMann, I've created a baseline set of workflows anyone can use. This is meant to set-up the correct triggers and files, NOT the actual CI (how to run the test/how to do x y z).

  1. I'm not looking for a long debate on how to optimise these further. This is meant to be an easy way for maintainers to get started with GitHub Actions, without having to do the research themselves. I invite further optimisations to be PR-ed in.
  2. This is not a great place for these files, but it's a good place for discoverability. Recommended by @iHiD , so we're good on that.
  3. I'm perfectly fine with changing wording, but please make a suggestion so it can be applied quickly, and then we can merge it in and make further improvements in future PRs.
  4. I'm not looking for a debate on where the scripts/binaries should be placed. Common places for scripts is scripts, common places for binaries is bin. Since it's literally only changing 1 line per script in the workflow, it's not worth debating. I purposefully made the migration example use bin/, and the other example use scripts/ to further establish that both are fine.

In short, the readme should be explanatory; you can drop-in the workflow files into your track, replace the template variables, and add the four scripts / bin files (you need to write these yourselves, in your language of choice) and it "just works".

+557 -76

0 comment

5 changed files

SleeplessByte

pr closed time in an hour

Pull request review commentexercism/problem-specifications

Add workflow recommendations and templates

+# 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

(If you want the wording to be better, PRs appreciated ❤️ 🙉)

SleeplessByte

comment created time in an hour

PullRequestReviewEvent

Pull request review commentexercism/problem-specifications

Add workflow recommendations and templates

+# 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>

Coming in a future PR 🏃

SleeplessByte

comment created time in an hour

PullRequestReviewEvent

push eventexercism/problem-specifications

Derk-Jan Karrenbeld

commit sha 4f635d8a34f5317bd598acc276230c9e18442b43

Apply suggestions from code review Co-authored-by: Jeremy Walker <jez.walker@gmail.com>

view details

push time in an hour

Pull request review commentexercism/problem-specifications

Add workflow recommendations and templates

+# 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]
      branches: [master, main]
SleeplessByte

comment created time in an hour

Pull request review commentexercism/problem-specifications

Add workflow recommendations and templates

+# 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
name: <track> / main

"main" here is doubly the better default branch name, and means "default".

SleeplessByte

comment created time in an hour

Pull request review commentexercism/problem-specifications

Add workflow recommendations and templates

+# 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]
    branches: [master, main]
SleeplessByte

comment created time in an hour

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentexercism/problem-specifications

Add workflow recommendations and templates

+# 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.

Yeah good idea. Lets' do that.

SleeplessByte

comment created time in an hour

PullRequestReviewEvent

Pull request review commentexercism/problem-specifications

Add workflow recommendations and templates

+# 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.

What's the "new" way?

SleeplessByte

comment created time in an hour

PullRequestReviewEvent

Pull request review commentexercism/problem-specifications

Add workflow recommendations and templates

+# 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 should be maintainers. Track is very ambigious.

Maintainers should be bound to code style, students should not.

SleeplessByte

comment created time in an hour

PullRequestReviewEvent

fork cmccandless/ruby

Exercism exercises in Ruby.

http://exercism.io/languages/ruby

fork in an hour

Pull request review commentexercism/common-lisp

Convert from travis to actions

            #: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.

You did! There was just nothing replacing the removed content.

verdammelt

comment created time in an hour

PullRequestReviewEvent

PR opened exercism/v3-website

<ConceptMap /> Feature: Highlight all ancestors, transition fade paths

This is a bigger PR comprising a new feature for the concept map and a significant refactor to incorporate transition fading.

  1. New feature: Highlight all ancestors

When hovering over a concept, it now highlights all ancestors required to unlock that concept and the paths taken to get there.

  1. With this new feature in place it became apparent that the previous strategy of a single canvas to render all of the paths was becoming too difficult to extend and maintain. Why? There was a split-second flash when paths overlapped concepts and caused a rendering gaffe. The gaffe is because the fading in of the paths was instantaneous and the concept boxes faded. To manage independent fade animations would be reinventing the wheel. So rather than having a single canvas, now a multi-canvas approach is taken so that the fading can all be managed with CSS. From my research (googling SO) this shouldn't be a performance issue.

The only downside is that it doesn't have fine-grain control over the layering, so at this point the paths may overlay each other unpredictably.


There is also a minor refactor to align ConceptState to ConceptStatus in the react component

+246 -216

0 comment

11 changed files

pr created time in an hour

pull request commentexercism/go

Move to GitHub Actions

Please note that workflows will not run from forks if they do not already exist in the target branch.

I can revert the removal of .travis.yml for now, so this can be merged to verify its functionality before dropping Travis entirely.

cmccandless

comment created time in an hour

PR opened exercism/go

Move to GitHub Actions

Resolves #1362

+71 -54

0 comment

4 changed files

pr created time in 2 hours

issue commentexercism/haxe

Moving from Travis to GitHub Actions

@ErikSchierboom

This has been outstanding for a couple of days now; is there someone else that needs to approve this before merging?

ErikSchierboom

comment created time in 2 hours

push eventexercism/configlet

Norbert Melzer

commit sha 6ab4a7a22be92ce743c8cdca873c4e9327fbb72e

[CI] update go versions (#178) Bump the used golang versions to the 2 most recent releases. This seems to be necessary, as #177 fails to build as the source code of the configlet uses some features that are not available in the foremerly used 1.8 and 1.9 of go.

view details

Norbert Melzer

commit sha e13f7c74c1d6840ecf92e746aa32dec12cb5febb

[fetch-configlet] make more portable (#177) This makes the `fetch-configlet` script more portable by using `/usr/bin/env bash` as the interpreter for the file. `/usr/bin/env` and its location are defined by POSIX, while `/bin/bash` is not, and different systems might have `bash` at different locations. Aside of that, even nixOS which does not follow POSIX rules and conventions, does provide `/usr/bin/env` by default, while making `bash` available at `/bin/bash` or any other (for nixOS) non-default location would require messing around with the system in ways that are considered a flaw within the nixOS community as they introduce impurities.

view details

Eric Kingery

commit sha 3829a706109704bfc20380983ffdb99ac42b100f

Upgrade to modules (#180) * switching to go modules, upgraded dependenciesmproved docs

view details

Eric Kingery

commit sha 86bf086c6fbb0486a43a4f499baffb5a8f2a8278

trimmed uuid before duplicate check (#171)

view details

Eric Kingery

commit sha f0c6cb1f8e2107387764c1f910ddaec641a70e2d

Merge branch 'master' of github.com:exercism/configlet into v3-upgrades

view details

Eric Kingery

commit sha bada9e228cc723bb064acea246cba95b342dd3f6

adding dist directory to ignore file

view details

push time in 3 hours

issue closedexercism/v3

[Python] Implement new Concept Exercise: list methods

This issue describes how to implement the list methods concept exercise for the Python track, which should familiarize the student with the core list methods.

Getting started

Please please please read the docs before starting. Posting PRs without reading these docs will be a lot more frustrating for you during the review cycle, and exhaust Exercism's maintainers' time. So, before diving into the implementation, please read up on the following documents:

Please also watch the following video:

Goal

This concept exercise should familiarize the student with some of the core list methods that manipulate/mutate lists, and when/how to use them.

Learning objectives

  • become familiar with the list class & its core methods
  • understand when when it is appropriate to use the methods of a list to operate on it
  • understand that these list methods mutate the list -- they do not return or make a new list.
  • use several of the list methods -- one at least from each grouping below to mutate a list:
    • add a single element/multiple (iterable) elements to the end of a list with the append()/extend() methods
    • insert an element before a given index position in a list with the insert() method
    • remove element at the given index & return it for use/delete it with the pop()/remove() methods
    • re-arrange list elements in place with the sort()/reverse() methods
    • return a shallow copy of a list with the copy() method
    • return count of the elements in a list with the count() method
    • return the index of the element in a list with the index() method
  • understand how the elements of two lists are compared

Out of scope

  • performance considerations
  • common sequence operations such as bracket notation, slice notation, min(), max(), and len()
  • related collections types, such as deque & UserList
  • list comprehensions
  • map() and reduce() for operations on a list
  • built-ins that can take a list as an argument
  • understanding how the elements of two lists are compared
  • shallow copy of a list with the copy() method vs deep_copy()

Concepts

  • container types
  • indexing
  • iterables
  • lists
  • methods of list
  • mutable, mutability
  • sequences, sequence types

Prerequisites

  • basics
  • booleans
  • iteration, iterables
  • loops
  • methods
  • sequences

Resources to refer to

Hints

  • Referring to one or more of the resources linked above, or analogous resources from a trusted source.

After

Explain more about:

  • The differences between methods of list & Pythons built-in methods called with a list as argument (e.g. reversed(), sorted(), len() ...).
  • mutability and its benefits/pitfalls
  • The common sequence operations that apply to all sequence types (binary data, text strings, lists, tuples, range)
  • Two-dimensional and n-dimensional lists
  • Slice assignment (aka "mutation hell")

Representer

No changes required.

Analyzer

No changes required.

Implementing

Tests should be written using unittest.TestCase and the test file named comparisons_test.py.

Help

If you have any questions while implementing the exercise, please post the questions as comments in this issue.

Edits

closed time in 3 hours

DavidGerva

issue commentexercism/v3

[Python] Implement new Concept Exercise: list methods

Since PR #2303 has been merged 🎉 , I am closing this issue.

DavidGerva

comment created time in 3 hours

issue closedexercism/v3

[Python] Implement new Concept Exercise: loops

This issue describes how to implement the loops concept exercise for the Python track.

Getting started

Please please please read the docs before starting. Posting PRs without reading these docs will be a lot more frustrating for you during the review cycle, and exhaust Exercism's maintainers' time. So, before diving into the implementation, please read up on the following documents:

Please also watch the following video:

Goal

This concept exercise should convey a basic understanding of how to handle loops in Python. This concept exercise should therefore teach the student the python while loops, for loops and should also teach how to interrupt or change the normal flow of a loop.

Learning objectives

  • use the while key to execute a loop: execute something as long as an expression is true
  • use a for loop to iterate over an iterable object with the for ... in pattern. The Membership testing concept (in) is required to address this concept.
  • understand the differences between while (condition-dependent) and for (length or iteration dependent) loops
  • use the break statement to terminate the nearest enclosing loop
  • use the continue statement to continue with the next cycle of the nearest enclosing loop
  • use the else clause to perform operation when a for loop terminates

Out of scope

  • async loops (advanced)

Concepts

  • while loops
  • for loops
  • the else clause to perform operation when the loop terminates
  • break statement
  • continue statement

Prerequisites

  • iterable objects and iteration base knowledge
  • collections
  • the Membership testing concept (in)

Resources to refer to

Hints

  • TBD?

After

Nothing

Representer

No changes required.

Analyzer

No changes required.

Implementing

Tests should be written using unittest.TestCase and the test file named bool_basic_test.py.

Help

If you have any questions while implementing the exercise, please post the questions as comments in this issue.

Edits

closed time in 3 hours

DavidGerva

issue commentexercism/v3

[Python] Implement new Concept Exercise: loops

Since PR #2302 has been merged 🌟 , I am closing this issue.

DavidGerva

comment created time in 3 hours

issue closedexercism/v3

[Python] Implement new Concept Exercise: none

This issue describes how to implement the none concept exercise for the Python track.

Getting started

Please please please read the docs before starting. Posting PRs without reading these docs will be a lot more frustrating for you during the review cycle, and exhaust Exercism's maintainers' time. So, before diving into the implementation, please read up on the following documents:

Please also watch the following video:

Goal

The goal of this exercise is to teach the student what None means and how None is used in Python.

Learning objectives

  • create a None object via literal declaration
  • check if an object is None
  • use a None object as a "False statement"

Out of scope

  • catching/raising Exceptions

Concepts

  • none

Prerequisites

  • builtin-types

Resources to refer to

Hints

  • TBD?

After

Nothing

Representer

No changes required.

Analyzer

No changes required.

Implementing

Tests should be written using unittest.TestCase and the test file named bool_basic_test.py.

Help

If you have any questions while implementing the exercise, please post the questions as comments in this issue.

Edits

  • edited for updated naming by @yawpitch

closed time in 3 hours

DavidGerva

issue commentexercism/v3

[Python] Implement new Concept Exercise: none

PR #2283 has been merged! 🎉 Closing.

DavidGerva

comment created time in 3 hours

issue closedexercism/v3

[Python] Implement new Concept Exercise: Enum

This issue describes how to implement the Enum concept exercise for the Python track.

Getting started

Please please please read the docs before starting. Posting PRs without reading these docs will be a lot more frustrating for you during the review cycle, and exhaust Exercism's maintainers' time. So, before diving into the implementation, please read up on the following documents:

Please also watch the following video:

Goal

The goal of this exercise is to teach the student how Enums (Enumerations) are implemented & used in Python. We will teach this through Pythons Enum class/type.

Learning objectives

  • What is an enumeration / enum is, and why they are needed/wanted in Python?

  • Understand the nomenclature (naming) used in reference to enums (e.g. enumeration/enum, enum members, enum member names, and enum member values)

  • Understand that enumeration members are functionally constants (and therefore should be formatted as such)

  • How Enums are different from other, more generic Python classes.

  • How to create various Enums

    • By using the class syntax by importing & subclassing Enum.
    • By using the Enum Functional API
    • By defining enum members with values that include non-int types (like str, tuple, float etc.)
    • Using the auto() function to automatically assign integer values to members when exact value types are unimportant/not needed.
    • Creating member aliases by assigning the same value to different names (two different names can have the same value; the second name defined becomes an alias of the first)
    • Using the class decorator @enum.unique to prevent member aliases and enforce that member values be unique.
  • How to use an enumeration and enumeration members in other functions/code

    • Enum members are iterable in member definition order, but iteration will not include aliases.
    • An ordered mapping of names to members can be retrieved via __members__.items()
    • enumeration members are compared by identity, using the is/is not keywords
    • Ordered comparison (<, >, <=, '>=) betweenenumeration valuesis not supported, and will throw aTypeError`.
    • Equality/inequality comparison is defined, and == and != can be used.
    • Comparisons between enumeration values and non-enumeration values will always return False

Out of scope

  • Flag enum subtype (perhaps better as an advanced exercise that includes bitwise operations)
  • IntEnum and IntFlag subtypes (since they break the semantic promises of an enum by being comparable to int)
  • mixins & multiple inheritance for the creation of Enums
  • using __new__() to customize the value of an enum member (better for an advanced/extended enum exercise)
  • omitting values
  • subclassing an "empty" pre-defined enum
  • customization of auto()
  • Pickling

Concepts

  • enumeration, enums

Prerequisites

  • decorators, @
  • __init__()
  • classes, OOP
  • inheritance
  • iteration
  • iterables
  • dunder methods
  • comparisons
  • rich comparisons
  • class attributes
  • importing
  • aliasing
  • dicts, dict methods (specifically dict.items())
  • mapping types
  • immutable,immutability
  • class properties

Resources to refer to

Hints

Should be focused on basic definition & use, and refer to one or more of the Python related links above (or equivalent/analogous links).

After

Some links and extended discussion of what problems an enumeration type is trying to solve in python programming might be useful to the student here. In particular, the rejected PEP354, and the subsequent accepted PEP435, as well as other discussion and links from the resources section.

It might also be useful to point the student toward all the rich customization options available for enum, such as the "interesting examples" section of the docs.

Finally, some discussion, links and usage around the "out of scope" cases above could be great to encourage the student to explore enums even further.

Representer

TBD

Analyzer

TBD

Implementing

Tests should be written using unittest.TestCase (we try to avoid using PyTest specific features), & the test file shoul dbe named enum_test.py.

Help

If you have any questions while implementing the exercise, please post the questions as comments in this issue, and/or reach out on the #python-maintainers channel in the exercism Slack team.

closed time in 3 hours

BethanyG

issue commentexercism/v3

[Python] Implement new Concept Exercise: Enum

PR #2312 Has been merged. Closing this issue.

BethanyG

comment created time in 3 hours

fork cmccandless/go

Exercism exercises in Go.

http://exercism.io/languages/go

fork in 3 hours

Pull request review commentexercism/common-lisp

Convert from travis to actions

            #: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.

ah! I thought I had caught all references to .travis.yml - drat!

verdammelt

comment created time in 3 hours

PullRequestReviewEvent

Pull request review commentexercism/common-lisp

Convert from travis to actions

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

So build on all branches and on pull requests onto any other branch? I'd have thought it would be better to limit it to only pull_requests to master - but I have no problem with doing more builds rather than less.

verdammelt

comment created time in 3 hours

PullRequestReviewEvent

pull request commentexercism/v3

[Python] basics - replace about.md file with concept files

@cmccandless - It's OK. That is what I get for using the GitHub web interface. It wasn't a lot of changes (just a nasty surprise). I'll PR it.

ErikSchierboom

comment created time in 3 hours

Pull request review commentexercism/common-lisp

Convert from travis to actions

            #: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.

Perhaps include an equivalent note for the new workflows?

See .github/workflows/ for CI workflow definitions
verdammelt

comment created time in 3 hours

Pull request review commentexercism/common-lisp

Convert from travis to actions

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

I would probably flip this:

on:
  push:
    branches: [master]
  pull_request:
verdammelt

comment created time in 3 hours

Pull request review commentexercism/common-lisp

Convert from travis to actions

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

Same as above; all branches

on:
  push:
  pull_request:
verdammelt

comment created time in 3 hours

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentexercism/v3

[Python] basics - replace about.md file with concept files

@BethanyG I'm so sorry! I hope you haven't lost too much work!

ErikSchierboom

comment created time in 3 hours

delete branch exercism/generic-test-runner

delete branch : codeowners-maintainers

delete time in 3 hours

push eventexercism/generic-test-runner

Erik Schierboom

commit sha b6b33cd58336bb9c986ffdebad078db2904dc902

Add exercism/maintainers-admin team as codeowner (#19)

view details

push time in 3 hours

PR merged exercism/generic-test-runner

Add exercism/maintainers-admin team as codeowner

The tooling is essential to the functioning of v3. To help ensure that any changes work well with the v3 website, the exercism/maintainers-admin team is added as a codeowner.

See https://github.com/exercism/exercism/issues/5400

+1 -0

0 comment

1 changed file

ErikSchierboom

pr closed time in 3 hours

PullRequestReviewEvent

push eventexercism/python-analyzer

Erik Schierboom

commit sha 64791cccb2d65ca6bc08903a101708fa5603dbf4

Add exercism/maintainers-admin team as codeowner (#15)

view details

push time in 3 hours

delete branch exercism/python-analyzer

delete branch : codeowners-maintainers

delete time in 3 hours

PR merged exercism/python-analyzer

Add exercism/maintainers-admin team as codeowner

The tooling is essential to the functioning of v3. To help ensure that any changes work well with the v3 website, the exercism/maintainers-admin team is added as a codeowner.

See https://github.com/exercism/exercism/issues/5400

+1 -0

0 comment

1 changed file

ErikSchierboom

pr closed time in 3 hours

PullRequestReviewEvent

pull request commentexercism/v3

[Python] basics - replace about.md file with concept files

@cmccandless -- I was working on this, and now you've nuked my changes!!

ErikSchierboom

comment created time in 3 hours

push eventexercism/v3

Erik Schierboom

commit sha 5269264b53808f87498db259a094ff0f05f0cd39

[Python] strings - replace about.md file with concept files (#2348) * [Python] Pre-populate strings concept's about.md file from after.md file * [Python] Pre-populate strings concept's links.json file from after.md file * [Python] strings - Remove after.md document * Apply suggestions from code review Removed exercise specific info and added more detail on the concept. Added and re-arranged links. * [CI] Format code Co-authored-by: BethanyG <BethanyG@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

view details

push time in 3 hours

delete branch exercism/v3

delete branch : python-strings-replace-after_md-with-concept-documents

delete time in 3 hours

PR merged exercism/v3

[Python] strings - replace about.md file with concept files track/python

In this issue we're describing an evolution of the specification of this repo. These changes include, amongst others, replacing the contents of the after.md document with individual concept documents. There are two documents per concept:

  1. An about.md file containing the description of the concept
  2. A links.json file containing a set of useful links related to the concept.

This looks as follows in the repo:

<track>
├── concepts
│   ├── <concept>
│   │   ├── about.md
│   │   └── links.json
│   └── ...

This PR applies this change to this exercise by:

  1. Copying the existing after.md file's contents to the about.md file of each concept listed in the exercise's concepts section in the config.json file.
  2. Extract the links from the after.md file and put them into the links.json file

Before merging this PR, please check that the contents of the concept documents makes sense. This is especially true when the exercise unlocks multiple concepts, as then the concept documents should be updated to only contain the information relevant to that concept.

Note: to make reviewing easier, the PR has been split into three separate commits. Please squash this PR upon merging.

+91 -15

1 comment

3 changed files

ErikSchierboom

pr closed time in 3 hours

pull request commentexercism/common-lisp

Convert from travis to actions

@exercism/github-actions Sorry to tag you after the PR was merged - but if y'all have time I'd love to have a review of the workflows I've created here. I'll be wanting to create workflows for the test-runner/analyzer/representer as well... so thought it might be a good idea to see if what I'm starting with makes sense. Thanks in advance.

verdammelt

comment created time in 3 hours

PullRequestReviewEvent

push eventexercism/cpp

Patrick Jackson

commit sha 7120f296345038ece4a9b073c10e84779a5e8136

Remove Travis CI (#367) * Remove Travis CI. * Remove all Travis references.

view details

push time in 3 hours

PR merged exercism/cpp

Remove Travis CI

Removes Travis in favor of only using Github Actions

Closes #365

+0 -85

1 comment

3 changed files

patricksjackson

pr closed time in 3 hours

issue closedexercism/cpp

Moving from Travis to GitHub Actions

Hello 🙂

Over the last few months we've been transferring all our CI from Travis to GitHub Actions (GHA). We've found that GHA are easier to work with, more reliable, and much much faster.

Based on our success with GHA and increasing intermittent failures on Travis, we have now decided to try and remove Travis from Exercism's org altogether and shift everything to GHA. This issue acts as a call to action if your track is still using Travis.

For most CI checks this should be a transposing from Travis' syntax to GHA syntax, and hopefully quite straightforward (see this PR for an example). However, if you do encounter any issues doing this, please ask on Slack where lots of us now have experience with GHA, or post a comment here and I'll tag relevant people. This would also make a good Hacktoberfest issue for anyone interested in making their first contribution 🙂

If you've already switched this track to GHA, please feel free to close this issue and ignore it.

Thanks!

closed time in 3 hours

ErikSchierboom

push eventexercism/cpp

Patrick Jackson

commit sha 3dd66480555986b832adea9270793dc29ee7c220

binary-search-tree: Add missing include. (#366)

view details

push time in 3 hours

PR merged exercism/cpp

binary-search-tree: Add missing include.

Adds a missing include that is causing a test failure in the clang-latest tests.

+1 -0

0 comment

1 changed file

patricksjackson

pr closed time in 3 hours

more