<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=21394) </details> <!--IssueSummary end--> ### Description Auto DevOps is great in that it runs a bunch of things, including tests, automatically for your code. But Herokuish, which it depends on, is really slow. If you provide a `Dockerfile`, we'll use that instead, but there's no equivalent for tests. We'll still run Herokuish for tests. Is there a convention people already use for testing Docker images? There's only one `cmd` per Docker image, so we can't deduce what test command to run. One [suggestion](https://gitlab.com/gitlab-org/gitlab-ce/issues/38366#note_49995754) is to detect a `Dockerfile-test`, build that, and run its default `cmd` for the test phase. Even if this isn't widespread yet, it's a reasonable convention we could recommend and adopt, especially since there's almost no downside. If you don't have it, we'll still default to Herokuish buildpacks, but if it is present, we'll use it. It's somewhat unlikely that `Dockerfile-test` would exist for another reason and you *wouldn't* want to use it for tests. The real problem is discoverability as this would likely be buried in documentation. With dynamic guides, we could recommend creating `Dockerfile` and `Dockerfile-test` when not present. Also, then our project templates could get rid of their `.gitlab-ci.yml` and just provide `Dockerfile` and `Dockerfile-test` files (and Helm charts if necessary) for more optimal pipelines. ### Proposal ### Links / references