Don't run Auto DevOps when no dockerfile or matching buildpack exists
Problem to solve
Currently we run auto devops automatically even for projects that:
- Don't have a dockerfile
- 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:
- Presence of a
Dockerfile - Presence of matching file for buildpack
bin/detect(ieGemfilefor Ruby,package.jsonfor node.js, etc). We'll just need to hardcode all the files listed inbin/detectfor all the supported buildpacks. - Presence of a custom
BUILDPACK_URLenvironment 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.
