Improve dev-env building and deployment #62

New issue

Open

opened 2024-01-19 09:58:21 +00:00 by fyrchik · 0 comments

fyrchik commented

2024-01-19 09:58:21 +00:00

Owner

There are 3 usecases:

Use dev-env to assist development (build, change, repeat).
Use dev-env for integration tests.
Use dev-env to play with the system.

The support for all usecases can be improved:

.env file contains component versions, which must exist in the docker hub. The problem with public hub is that few people have access. The problem with our private hub is limited disk space.
This leads to another problem: to build with local environments I must have some repository cloned, then build docker image, then copy this to env. Far from ideal.

The idea is to allow building everything from this repo.
We must allow configuring local overrides, which are not stored in git. So if my local config is frostfs-node: /home/user/frostfs-node, make build (or sth similar) builds image from the currently checkouted branch.
The default is to point everything at the last release or master branches.

In the result:

For the first usecase I just change the code, then do make rebuild (do not copy new image ID in .env)
The second usecase could take advantage of easy builds, so that this repo is everything we need.
The third usecase could allow easier experimenting: if there is a problem in some component, I should just change the commit, and not thinking whether some random image is pushed onto dockerhub.

Possible tool to use is https://android.googlesource.com/tools/repo

There are 3 usecases: 1. Use dev-env to assist development (build, change, repeat). 2. Use dev-env for integration tests. 3. Use dev-env to play with the system. The support for all usecases can be improved: 1. `.env` file contains component versions, which must exist in the docker hub. The problem with public hub is that few people have access. The problem with our private hub is limited disk space. 2. This leads to another problem: to build with local environments I must have some repository cloned, then build docker image, then copy this to env. Far from ideal. The idea is to allow building everything from this repo. We must allow configuring local overrides, which are not stored in git. So if my local config is `frostfs-node: /home/user/frostfs-node`, `make build` (or sth similar) builds image from the currently checkouted branch. The default is to point everything at the last release or master branches. In the result: 1. For the first usecase I just change the code, then do `make rebuild` (do not copy new image ID in `.env`) 2. The second usecase could take advantage of easy builds, so that this repo is everything we need. 3. The third usecase could allow easier experimenting: if there is a problem in some component, I should just change the commit, and not thinking whether some random image is pushed onto dockerhub. Possible tool to use is https://android.googlesource.com/tools/repo

👍 3