@crdant we're now going to be putting these in https://github.com/replicatedhq/platform-examples right?

GitLab seems unhappy with the .yaml expression. When I changed it to .yml it was happy.

You're absolutely right. It can be changed in the GitLab settings, but indeed to remove the confusion it's better to rename it to a default value.

I believe this should be moved to platform-examples same as we've done with the github workflows. See #26 which is removing the examples from this repo.

Is CD something we want to make sure we encourage with every repo? If it is I wonder if it's an example or it's something to include in the starter. I have arguments in my mind in favor of both approaches:

1. If we include CD in the starter we're endorsing a particular CD (or a few) and potentially own mistakes people make with it, especially if they adopt one of our examples even when they're using something else. They de facto do that with Github if we include a github workflow.
2. If we don't include CD are we leaving something critical out of the starter, since we want to make sure everyone delivers continuously to Replicated according to our best practices.

That's a good question, I was using the recommendation "You shouldn't have to remove anything from your starter repo".

Using that filter, GitLab and GitHub CI wouldn't belong here since you need to remove at least one of them. Expanding to other CI options will only make that grow.

I could see the argument since the repo is on Github we setup the github workflows in the repo and you don't need to remove them. Then we have the same things you mention above, having to maintain them and possibly customize them with users.

I don't suppose there's a perfect answer either way. I think I lean toward just not putting any CI in the repo, and give examples that people can drop in and use. They have to configure their environment variables to make them work anyway so it's never completely hands off.