The Crystal Programming Language Forum

Migrate CI in crystal-lang projects

Some of our crystal-lang repositories still use Travis CI which is just broken because the update to use the new OBS repositories is not getting merged. It seems like travis is rapidly declining anyways, so it’s really a good idea to move away.

We have been consolidating on Github Actions for crystal-lang/crystal and a couple more main repos (crystal-lang/shards, rystal-lang/crystal-book).

Most of the shard repositories and others are still using travis. They should be migrated to Github Actions.

There are also some of CircleCI configurations (at least in crystal-lang/distribution-scripts) which works fine but we could migrate them to Github Actions as well to standardize on a single setup. Definitely not a priority, though.

7 Likes

(Note to @core-team: I initially posted this thread in the Core Corner, but it was intended for Crystal Contrib, so please be aware that I transferred it here after publishing it.)

Do you need any help with this? Is it ok for devs to go ahead and start contributing? I’m definitely interested. Is there a place where you have these items logged as todo? (Trello, JIRA, GitHub Issues, etc)

Sure, help is definitely welcome. Thanks!
We should still wait for comments from other core members though, before starting a big effort.

We should probably coordinate and standardize the specific CI configuration (like which versions to test against) between all repositories. Not that every one should get the exact same settings (there are probably some specific differences), but to have a general plan on what we do.

We’re already using Github Actions on crystal-db shard (crystal-db/ci.yml at master · crystal-lang/crystal-db · GitHub) and probably just take that as basis for other shards.
I would suggest to add 1.0.0 to the version matrix explicitly. Currently, it’s identical to latest, but after the next minor releases we should probably still aim for compatibility with 1.0. It doesn’t need to be strictly enforced, but at least we should know about it and make an informed decision. Hence we should have it on CI.

(I created a PR against crystal-db to fix that there: Update Github Actions config by straight-shoota · Pull Request #152 · crystal-lang/crystal-db · GitHub)

We also might want to revisit starter-workflows/crystal.yml at e254b12b67be2492ce6e921410fc39944010bed1 · actions/starter-workflows · GitHub

1 Like

So, what do we want that starter workflow to look like? I’d presume, it should probably be a rather minimal configuration and contain a link to the configurator for customizing.

This is the minimal configurator output (using shards install for an app):

# This CI job installs Crystal and shard dependencies, then executes `crystal spec` to run the test suite
# More configuration options are available at https://crystal-lang.github.io/install-crystal/configurator.html
name: Crystal Spec

on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Download source
        uses: actions/checkout@v2
      - name: Install Crystal
        uses: crystal-lang/install-crystal@v1
      - name: Install shards
        run: shards install --ignore-crystal-version
      - name: Run tests
        run: crystal spec --order=random
      - name: Build
        run: shards build

The on section is copied from the current workflow.

Adding the introductory comment and name might be a good idea for the configurator, as well.

1 Like

How about a starter that covers multiple platforms, with some comments for what to comment out or to edit as applicable?

That starter might include the sekeleton of a version matrix to make it easy to manually add other versions of Crystal to the mix.

I presume the great majority of shards does not have any platform-specific code. Testing on a single platform should be completely sufficient. Let’s keep the starter simple. IMO a reference to the configurator is good enough for advanced use cases.

1 Like

You’re probably right.

Some official templates of any configuration would be great. I kinda scavenged from various Crystal github workflow config files.

I was kinda getting at was some sort of official Crystal docs re how to do CI for a shard or app that a dev might want to be compatible with the ‘currently supported platforms’ or possibly with ‘soon to-be currently supported platforms’ or with ‘my platform of interest’.

As Crystal expands to more platforms, some doc’s and maybe some templates/examples might be good. At least I think so. You all feel free to chime in and correct me where I’m off.

The install-crystal configurator is the official resource for this. It not just shows examples, it even let’s you customize them for your needs via a simple form.
https://crystal-lang.github.io/install-crystal/configurator.html

And there’s GitHub Actions - Crystal guide in the book.

1 Like

@straight-shoota , Awesome; thanks! :slight_smile: