-
Notifications
You must be signed in to change notification settings - Fork 7
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
building from workspace is not possible with inherited or path depencies #40
Comments
@laurentsenta @mxinden would you have a workaround for this? So far I've searched in the documentation ways of setting the dockerfile path from the manifest and have the dockerfiles in the root
If there is a way to do this I have not found it Also moving the dockerfiles one directory up and passing as parameter to the testground cli. This also doesn't seem to work |
The followings are how I'm running planA for now. That works but not cool...
# checkout https://github.com/testground/testground/pull/1503 and run `make install`
cd path/to/ackintosh/testground
make install
name = "planA"
[defaults]
builder = "docker:generic"
runner = "local:docker"
[builders."docker:generic"]
enabled = true
+ dockerfile = "planA.Dockerfile"
[[testcases]]
name = "planA"
$ ls -l ~/testground/plans/
related-testground-plans -> /path/to/related-testground-plans
# NOTE: Pass `related-testground-plans`, not `planA` to the `--plan` param.
testground run single --plan=related-testground-plans --testcase=planA --builder=docker:generic --runner=local:docker --instances=16 You can also run |
Thanks for reaching out @divagant-martian and for sharing a solution @ackintosh ! I'm not familiar with rust workspaces and I'd like to take some time to learn about your use case and improve support
This is how I would do this for now: Define your test at the root of your workspace (single manifest at the root), The structure would look this:
Then in a composition file, use the [[groups]]
id = "plan-a"
instances = { count = 2 }
builder = "docker:generic"
[groups.build_config]
path = "planA/" Then in the Dockerfile, copy the whole source folder ( ARG image
FROM ${image} AS builder
WORKDIR /build
ENV CGO_ENABLED 0
COPY . .
ARG PLAN_PATH
# you can access every subfolders here,
# for example:
RUN cat plan/planA/Cargo.toml
RUN cat plan/planB/Cargo.toml
# you can use `PLAN_PATH` to build the "right" plan:
RUN cd plan/${PLAN_PATH} && cargo build
FROM ${image}
COPY --from=builder /testplan /testplan
EXPOSE 6060
ENTRYPOINT [ "/testplan"] You can then switch between plan by using a different |
@laurentsenta I checked the plans you linked but I'm still not sure how to apply them, haven't tried hard enough tbh so will do that. Caveats:
|
Thanks for sharing your example repo, I took some time to fix it, this might become a useful example. When you call By then your docker builder, and The solution is to make sure your test plan is defined at the root folder of your source, then use a composition file with a [groups.build_config]
path = "planA/" I updated your repo to support workspaces and proposed 2 compositions (hardcoded plus a generic one). |
it took me a bit as well to apply it to a project, but it proved useful. I think it would be nice to document this somewhere. What would be the best place for this? |
Also, After some effort and more than a couple mistakes I managed to cache dependencies in the workspace using https://crates.io/crates/cargo-chef |
Nice, could you share your setup? It's probably something we'll want to reuse and share, and eventually turn into a native Testground builder. At the moment, because this would be mostly rust-specific (workspace, cargo-chef, etc) I'd recommend we create a doc folder in this repo. @mxinden wdyt? |
Here is the setup applied to our example repo divagant-martian/shared-deps-testground-example@941464f |
Do I understand that the approach taken with Lines 4 to 11 in 2b85e4c
If so, would you mind proposing a pull request to this repository @divagant-martian? That would make the discussion more concrete and thus easier. |
More of a tracking issue that falls more on testground itself: Using workspaces is not really possible/useful right now.
In a scenario like this:
the
utility
directory currently is not accessible from the docker build context. An option would be able to define the testplans in the root of the directory but I don't see a way. Maybe related testground/testground#1466This makes rust workspaces particularly disadvantageous
The text was updated successfully, but these errors were encountered: