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.
(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.
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.
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.
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.
