visciang / mbs Goto Github PK

Push mix coveralls stats and add badge to the README file.

...with its tests

Maybe move the example folder in this new repository.
Should be wired with files cache and docker cache.

Ref: #27

Idea:
Should we give the possibility to use an "external toolchain"? (just an external docker image)
This would be a little escape from the monorepo ...

{
  "id": "docker_app",
  "component": {
    "external_toolchain": "mbs-docker:xxx",
    "files": [
        "hello.sh",
        "Dockerfile"
    ],
    "targets": [
        "docker://docker_app"
    ]
  }
}

Currently we support "targets dependencies":

Component X builds and produce targets x1, x2
Another component Y depends on X and so it's build will receive as inputs all the X targets.

Some languages are more source dependencies based, they don't produce intermediate artifacts that can be that consumed by dependent components. Golang is one example.
There are also languages that can produce and consume intermediate artifact but is much more convenient to "source depend" in a mono-repository.

Investigate about the possibility to "source depend".
In this case the dependent component will see all the dependencies targets (transitive closure) and also their source dirs.

cache command (purge | size | info ...)

Possibility to pass secrets to the toolchains (for both mbs build run and mbs deploy run).

mbs build run --secret S1=1 --secret S2=2 ...
mbs build run --secret-file secrets.txt

Currently we have "docker run ..." for each toolchain step.
This is "slow" (every docker run takes 300 ms) and makes sandboxing tricky.

Better to switch to a

• docker run --name toolchain-x --detached ... sleep
• docker exec toolchain-x /toolchain.sh step_1
• docker exec toolchain-x /toolchain.sh ...
• docker stop toolchain-x

This issue is needed before #3

Investigate buildx builds to leverage the buildkit isolation.

Maybe good for:

• cache isolation
• docker build context import/export (ci caching)

Additional:
MBS should ship with a builting toolchain, the "docker" toolchain, that every project can (or better should) use to build docker images. Doing so we can "buildx" every docker image!

Should be applicable to mbs build run and mbs deploy run.

Something like:
mbs build run --verbose --log-dir ./build_logs

The MBS.Reporter process should stream each job log stream to a specific file under the --log-dir directory

Should be possible to define multiple toolchains / components in the same manifest file.

This feature can be used to implement different build patters such as:

• Building the same component into multiple flavors / versions, maybe using different toolchains
• External dependency "caching"

Add some metadata to the toolchains docker images via --label.

At least:

• mbs-project-id=$MBS_PROJECT_ID

Investigate or simply let TLS on (implies we have to share client certificates beetween MBS container and DIND container).
First investigate why the boot is slower with TLS disable, actually we don't need at all this local (and isolated) connection to run over TLS.

MBS_PROJECT_ID in mbs.sh / mbs.fish is not correctly filled with the current project name

It would be good to leverage image metadata (label mbs-project-id) to collect all the toolchain image to rm.

Needs #20