`Fork` as Heroku Button

Heroku Button is an awesome way to "distribute" software such that people can click a button and get a running version of your software quickly and easily. As we add more deployment tools, a natural question comes up; do we need a "GitLab Button"?

Well interestingly, we already have it. It's called "Fork". You should just need to fork an open source project into your namespace, and we'll use Auto DevOps to build and deploy it.

Now technically, we don't trigger CI/CD on forks; presumably because there's little value in re-testing something with zero changes. But since pipelines are more than tests, we should reconsider that choice. Should we just run a regular pipeline on master after fork? Should we special case forking somehow, perhaps with only and except so you can opt out of re-running CI tests if there are no code changes? That's probably not worth the hassle. Maybe there should be an option to run CI/CD on master in the fork dialog.

Of course Heroku Button is a lot more than just forking and deploying; it also defines required and optional project variables, creates secrets, spins up addon resources, etc. These things are increasingly covered by Helm charts (which Auto DevOps uses), but unfortunately don't cover completely. There's still no easy way to auto-generate a project-specific secret, for example.

Some options:

Use app.json, which is used by Heroku Button (and was originally envisioned as a platform-agnostic configuration, but in reality is pretty tied to Heroku's addon ecosystem)
Work with Helm to resolve deficiencies (secrets, required variables)
Create something else

`Fork` as Heroku Button

Links