reuse build, e.g. for workers
Problem
both kubernetes and cloud-run support to spin up multiple resources, e.g. in cloud run you can create a service and some jobs (currently there is even unused support for creating multiple services).
This is convenient in some cases, because you don't need to specify another component and just can reuse the same image with a different command.
For jobs and cronjobs, thats works nice and is simple enough.
However, if you want to have an additional service, e.g. a worker that should also react to http requests, you have a problem: what is the ROOT_ URL of that worker?
The problem is that catladder is designed that each component has one ROOT_URL and one set of env variables.
This approach one component = one webservices (and also = one gitlab environment) is correct in my opinion because it gives a clear separation of env vars, you can have dedicated tests for your worker, etc.
Solution
The reason why you want to have multiple outputs in the same component is convenience, because you don't need to define an additional build script for your additional service/worker. So a compromise would be that you would have each service as its own component, but could reuse the build
Proposal:
- new build type "reuseFromComponent" (tbd)
- has a property "component: string" where you reference that other component
- this component then would not add any build steps (nor tests). Its deploy script instead would use the docker-image of the referenced component instead, or the dist folder of that other component's build (in cases where the deploy step does not need docker)
preparations
i started to refactor the "needs" handling a bit here !99 (merged)
The goal is to support specifing an optional other component in needsStages
the idea is that when component B reuses build from A, the deploy-scripts would then simply add the other component to its needsStages
(it currently has needsStages: [{stage: "test}, ...]
). That way, the deploy would wait for the other build. Also it would already handle the non-docker case and import the artifacts). For the docker case, some small adjustments are needed to use the right docker image in the deploy script