GitLab Next

Problem to solve

Currently we run auto devops automatically even for projects that:

1. Don't have a dockerfile
2. Don't have a matching buildpack

This leads to unnecessary cycles and user dissatisfaction as they often don't understand why their project is showing failures.

Target audience

• Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha

• Devon, DevOps Engineer, https://design.gitlab.com/research/personas#persona-devon

Further details

Proposal

When Auto DevOps is enabled, evaluate if a build mechanism exists before running. If no build mechanism, disable Auto DevOps. Mechanisms to consider should include:

1. Presence of a Dockerfile
2. Presence of matching file for buildpack bin/detect (ie Gemfile for Ruby, package.json for node.js, etc). We'll just need to hardcode all the files listed in bin/detect for all the supported buildpacks.
3. Presence of a custom BUILDPACK_URL environment variable

This should only happen when Auto DevOps is "implicitly" enabled and not when explicitly enabled as someone that has explicitly enabled Auto DevOps will want to see a failing pipeline to understand why it's not working.

We should also ensure the logic to check if the files exist is based on the SHA for which we are currently creating a pipeline (and not just looking at master for example).

Lastly, if the check runs and no Dockerfile or matching buildpack are found AND Auto DevOps has been enabled implicitly for the project in question, we should inform user about this fact in the Auto DevOps settings section by displaying a warning alert that reads:

You must add a Dockerfile or supported buildpack in order for the Auto DevOps pipeline to run. More information

If the correct file is added, we should automatically run the pipeline.

What does success look like, and how can we measure that?

We should track the instances where this evaluation returned true or false to start.

Links / references