-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(jstzd): implement image #553
Conversation
e3ef180
to
254bca3
Compare
Codecov ReportAttention: Patch coverage is
Continue to review full report in Codecov by Sentry.
|
08c563d
to
7eda38d
Compare
The manual test fails with |
Commit messages are missing scope. Prefer to include it if possible. |
Additionally in future, I suggest we stick to 1 linear task per a PR. This single PR partially closes 4 (some support is missing here and there). This will not only make task tracking easier (and fits more nicely into linear's workflow), but will make reviews easier |
7eda38d
to
c63d91c
Compare
I accidentally removed the pull image code in the example since it was pulled in my local machin, i've added it back so should work now! |
c63d91c
to
c6f4151
Compare
feae871
to
1d068e4
Compare
1d068e4
to
9e13d12
Compare
9e13d12
to
b330d0f
Compare
What was the reason/advantage for using rust to generate docker image rather thank just using a Dockerfile and docker-compose? |
This work doesn't generate docker images but automates pulling and running them in containers @jasbir-dhillon. These APIs will ultimately be used to orchestrate the jstzd sandbox environment. |
@zcabter Could that have been done by just using a docker-compose file. You would of needed less lines of code and it would have been more readable? |
crates/jstzd/src/docker/container.rs
Outdated
let mut this = std::mem::take(self); | ||
// Prevent the original `self` to drop again | ||
self.dropped = true; | ||
TokioScope::scope_and_block(|s| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a note about scope_and_block
: this only works with a multi-threaded runtime. Otherwise, the code will panic here. Sample error message:
thread '...' panicked at ...:
can call blocking only when running on the multi-threaded runtime
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh didn't notice that, the number of threads in tokio runtime defaults to the number of cpus on the system so i guess we can assume it is multithreaded ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realised that this is not just for scope_and_block
but for blocking async in general, e.g. tokio::task::block_in_place
.
I guess we can keep that assumption for now. For unit tests this might fail since single-threaded runtime is used by default. This can be resolved with #[tokio::test(flavor = "multi_thread")]
.
It could but we'd still need to write an api over it as Docker is just one of |
The testing coverage is a bit low partly because integration tests are missing. I know you put a lot of effort into this but I think this PR needs to be broken down into 4 PRs, 1 per issue. Where we are running docker commands, it needs to be Additionally, I suggest removing the async dropper and custom drop logic for now since it will be re-thought (per #555 (comment)) but keeping the clean up logic. |
b330d0f
to
605ae93
Compare
I've split into three PRs, the first one doesn't require integration test so it could be merged. The 2 and 3 pr is tested manually and it only does the basic stuff so I personally don't think there's much problem merging it so we can see something is working. I've also removed the drop for now in the 3rd pr.
|
self | ||
} | ||
|
||
pub async fn create_container(&self, client: Arc<Docker>) -> Result<String> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would move all asssociated logic for create_container
(aka start
) under a different PR (will help with your testing).
The task is: https://linear.app/tezos/issue/JSTZ-62/implement-start-for-runnableimage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done, i will add this back after the pull image PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this should be a separate PR -- it is a different task to pull_image
605ae93
to
fc310d6
Compare
0bc953f
to
8a664b6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm 🚀
Context
Implement traits / struct to run docker container that can later be used for jstzd
The related tasks are the following but not all of them are fully covered/tested yet (e.g. mounts/hosts etc)
image
runnable image
Description
Implement the docker images traits and structs
Manually testing the PR
cargo test --package jstzd --lib