Provide default runtime Dockerfiles

[michaelsauter]

We could provide default runtime Dockerfiles in the build tasks. For example, we could provide the following Dockerfile in ods-build-go:

FROM alpine
COPY app app
EXPOSE 8080
CMD ["./app"]

This file would be copied into the workspace if docker/Dockerfile does not already exist.

The background of this idea is that many applications do not actually need to modify the Dockerfile, so we do not need to require users to provide one in the first place. This would reduce the setup effort. As a further benefit, we would be able to provide updates to the Dockerfile within the same lifecycle as the tasks, ensuring everything is up-to-date and aligned.

In theory, this concept could also be expanded to other aspects, such as sonar-project.properties or even Helm charts.

FYI @velcrin based on our discussion just now ;)

[renedupont]

Two questions came up my mind:

• Would it be somehow transparent to the dev how his app was being deployed? So that it does not feel like something unknown magically happening in the back.
• What about use-cases where a code repo runs through the pipeline but does not need to be deployed at the end and thereby needs no dockerfile? Idk, maybe like a library component or something.

[michaelsauter]

Would it be somehow transparent to the dev how his app was being deployed? So that it does not feel like something unknown magically happening in the back.

I'd propose to use the same approach as with the SQ config: just add log output saying that there is no dockerfile, and printing the content of the default dockerfile to the log.

What about use-cases where a code repo runs through the pipeline but does not need to be deployed at the end and thereby needs no dockerfile? Idk, maybe like a library component or something.

The build task would create a dockerfile, but nothing would happen with it. Maybe odd but doesn't necessarily hurt I think.

That said - if this whole feature makes sense at all ... not sure :)

[michaelsauter]

Closing as a consequence of #722.

The feature could be added to individual build tasks, or the package image task could support a few languages out of the box. But for now it is not clear whether this has a huge benefit.