Crystal: CircleCI config on init tool

[Daniel-Worrall]

With the init tool, we have some great core functionality for any new Crystal app or lib, but it currently only supplies a travis example config. We don't even use travis for the language testing. I feel like this is something the language can easily provide since docker builds are automated.

I have drafted up an example config.yml for CircleCI based around Circle's Public recommendation for Crystal here without specs.

version: 2
jobs:
  build: 
    working_directory: ~/<%= config.name %>
    docker:
      - image: crystallang/crystal:latest
    steps:
      - checkout
      - restore_cache:
          key: dependency-cache-{{ checksum "shard.lock" }}
      - run: shards install
      - save_cache:
          key: dependency-cache-{{ checksum "shard.lock" }}
          paths:
            - ./lib
      - run: crystal spec
      - run: crystal tool format --check

[hugopl]

Add travis config, circle CI config , and XYZ config at crystal init IMO is too much, I always need to delete e.g. .editorconfig file when I do crystal init, so IMO adding this as default would be just another file I may need to delete after calling crystal init, if project continue like that in a later future we are going to need to delete more files created by crystal init than files we want to keep.

i.e. IMO all this should be default to opt-out, then I enable e.g. --circle-ci, --whatever-editor-use-dot-editorconfig, etc... and voilà, the files you want will be created.

[asterite]

I think crystal init should be a wizard that asks you stuff, similar to lucky init.

[j8r]

I really think crystal init should be a separate tool by itself, not included inside the compiler.
There are way to many features that can be added, and shouldn't in this repo because they are not directly related to the language itself.

Is the goal to become like Yeoman? I see more disadvantages of having crystal init than crystal-init.

The templates could also be fetched remotely.

[j8r]

In fact @asterite , lucky_cli is a separate project repository from lucky - Crystal can do the same, yes.

[asterite]

crystal init should be a wizard and should be available when you install crystal. Better? :-)

[straight-shoota]

Short term, I'd support adding circle ci config. The future development of crystal init is a separate topic.

[j8r]

Not really, because one can also create another issue to support Drone CI, then GitHub Actions, and so on.
So, it's good to have this discussion to put a direction before continuing any development.

The wizard binary can be bundled like shards, that was crystal deps.

[ysbaddaden]

My two cents: there are zero reasons to favor a CI over another one. Until we have an interactive/configurable wizard, and templates for many CI, we shouldn't generate a CI configuration.

[Daniel-Worrall]

I'm definitely in favor of a configurable wizard, and this is a mostly static template so can be referenced while the wizard is in development.

If anyone has any thoughts on the template itself, let it be known, but perhaps the init wizard should be a separate issue.

[hugopl]

A wizard with command line options to bypass the questions.