Hello GitHub Actions ✅, Bye Bye Travis 👋

[buschtoens]

I just setup my first GitHub Actions for an Ember addon: buschtoens/ember-link#291 (Thanks @dfreeman! :beers:)

It was super simple and so far works perfectly. 😍

I propose we add something similar to .github/workflows/ci.yml to the default blueprints and remove .travis.yml in exchange. One awesome side-effect of this is that it will just work, without the repo maintainer having to sign up with and link Travis for every new repo.

I'm not sure, whether this needs a fully-fledged RFCs, but I'd be happy to submit one and also champion the implementation.

All in favor say 👍 ? 😄

[buschtoens]

We might also wanna add .dependabot/config.yml, while we're at it! 🤖

I'm unsure, whether we should enable auto-merge by default though. Even though CI would be enabled by default now (thanks to GitHub Actions), not everyone always writes (good enough) tests. I could imagine that quite a few people would be annoyed, if their dependencies suddenly started changing beneath their feet. 😅

Also here, happy to RFC this, if necessary.

[nightire]

We might also wanna add .dependabot/config.yml, while we're at it! 🤖

The link above should be: https://github.com/buschtoens/ember-link/blob/master/.dependabot/config.yml

[buschtoens]

@nightire Good catch, thanks! I fixed the link.

[buschtoens]

One concern that was raised: We should not default to any provider, or at least should make it convenient to choose.

Taking this into account, I would propose to not ditch Travis completely, but rather add a new flag / option to the blueprints, defaulting to GitHub Actions.

[Alonski]

I had a similar thought a year or so ago. That we should maintain multiple configurations for different CI providers and allow adding them via blueprints.

[sivakumar-kailasam]

I'd love to see this as a part of ember-ci & include ember-ci in ember-cli so that we don't default to any provider but rather provide the blueprints to choose one.

[alexlafroscia]

I’m definitely interested in this change!

Here is one configuration that I’ve used for an Ember addon in the past. I have it install dependencies once and then parallelize linting with our ember-try test cases.

[ef4]

I wonder if we can’t do more with the welcome page that every new app gets. It could have buttons on it that install the different CI configs, choose the lang to put into the HTML, etc.

This would be one way to nudge people toward post-creation steps they might otherwise forget, for the cases where we have a good reason not to pick the default for them.

All of this can be done with the existing addon API, because addons can install dev middleware for the “backend”.

[jrjohnson]

We've been much happier running our ember-try tests on a daily schedule instead of with every integration and this is really easy to accomplish with Github Actions. This still allows us to spot future issues and start working on them, but doesn't hold up development while upstream blockers to upgrading exist.

[jaydgruber]

I think an addon w/ default ci configs for various platforms would be super useful. I'm not sure how to provide the optional extras though. Like here is your default ci config. Now you want ember-cli-template-lint, ember-exam, ember-try. Commented out jobs in the yaml? Addon repo has multiple yaml examples? I'd be happy to contribute for Jenkinsfiles, gitlab-ci. Currently on gitlab

[tylerturdenpants]

I think it would be cool to add configurations for coverage/climate report while making this transition. This seems to be a popular step during CI.

[sandstrom]

Not necessarily against this idea, but I've always thought that I'd rather not have the .travis.yml file added by default.

Perhaps there is a better way of helping people out with CI-setup, for example a section in the Ember Guides? "Here is how you setup your Ember app with Continuous Integration under different providers…"

[pzuraq]

For addons at least, I'm really glad that we have a default setup for CI OOTB. It just makes setting up a new library much, much easier, and I think it's a major part of the reason the ecosystem has done so well.

I do think it'd be good to have a setup section for apps though, given CI changes from company to company and we can't expect there to be one solution that fits everyone.

[runspired]

I recently did an nice thing for having cross-browser testing for dev/prod/fastboot across devices on GitHub-actions:

https://github.com/html-next/skyrocket/tree/master/packages/testem-safari-webdriver-launcher https://github.com/html-next/skyrocket/blob/master/packages/ember/testem.js https://github.com/html-next/skyrocket/blob/master/.github/workflows/main.yml#L44-L79

[mehulkar]

FWIW, these config files that integrate 3rd party services are kinda annoying for enterprise users. You want to delete them, but then every ember-cli-update brings them back 😢. I think they should live in the Guides rather than templates. Linking to those guides or adding content to the Welcome page seems like a great idea. An npx script that can generate the defaults would be even better. Or the inverse ember new --enterprise or something.

[rwjblue]

FWIW, these config files that integrate 3rd party services are kinda annoying for enterprise users.

Yes, agreed.

You want to delete them, but then every ember-cli-update brings them back 😢.

Well, not every update, but many. ember-cli-update will only bring back the .travis.yml when the upstream blueprint contained changes to the .travis.yml. Either way, I still totally agree that it is annoying / frustrating.

I think they should live in the Guides rather than templates.

I don't quite agree, but I do think that we should work to make their inclusion an opt-in not an opt-out. Concretely, I want to work on (or help someone else author) an RFC that does something like:

• Add a ember new / ember addon option for --ci which defaults to travis
• Add a blueprint for ember generate ci-configuration <name of ci service> and move the .travis.yml into this blueprint
• Add support to the ci-configuration blueprint for other CI providers (personally I'm most interested in github actions, but I think this needs to be a "big tent" scenario where we'd accept basically any PRs to add similar CI configurations for alternative providers).

This part alone fixes the main frustration you mentioned (RE: ember-cli-update bringing things back) once paired with the changes in https://github.com/ember-cli/ember-cli/pull/9238, but we can continue further by considering (in a second RFC) making the ember new workflow (when executed without an application name) be more "wizard like".

[rwjblue]

@buschtoens - Are you still interested in working on the RFC for this?

[buschtoens]

@rwjblue totally! I'll flesh something out in the next days based on your previous comment. Thanks!

[bertdeblock]

Is this something we can close now that https://github.com/ember-cli/ember-cli/pull/9579 is merged and https://github.com/ember-cli/ember-cli/pull/9644 on the way?

[locks]

Yeah, seems like it @bertdeblock!