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.

[Daniel-Worrall]

@oprypin made a tool for configuring a GitHub action similar to the rest of the suggestions here. I'd love to see this adapted to the initialise tool, with travis and circle added. https://oprypin.github.io/install-crystal/configurator.html

[j8r]

I suggest to remove the .travis.yml file. GitHub Actions is more and more used in favor of Travis CI.

As I and others said previously, no need to favor few people using a particular service. It is best to have such tool outside the compiler. Being bundled or not in the release process is another story.

[oprypin]

Thanks for the mention.

I wouldn't want https://oprypin.github.io/install-crystal/configurator.html to be bastardized into a CLI. The nice thing about that UI is it lets you see the config change/grow as you add features and you can change your mind any time in an informed way.

Regardless of the final outcome, I am 100% convinced that .travis.yml should be dropped at least for now. Having nothing is definitely better than having just it.

But it's also my long-term wish to not add any CI config as a file. Just at the end of the wizard, print out a suggestion to consider adding CI, with links to a few options.

All of this said, I never used this init tool and never will.

[straight-shoota]

All of this said, I never used this init tool and never will.

The thing about crystal init is that most people probably don't use it often. Even if you use it when you create a new Crystal project, that typically doesn't happen very frequently. And power users could even use other means to initialize a new project. But it's a tool that most new users likely run it as one of the first things they do with Crystal. So it should really leave a good first impression, even if the total impact might not be that high.

[j8r]

I suggest to continue the discussion on the forum (https://forum.crystal-lang.org/t/poll-how-do-you-use-crystal-init/2921) or the crystal init RFC https://github.com/crystal-lang/crystal/issues/8844, to avoid one issue per wanted crystal init feature. Lots of people would like to have more features in this tools.