There's a bug in test_create_lockfile_specification_auth. This test sends a POST to /specification/ which initiates a build; then it grabs the resulting lockfile produced by the build, and sends another POST to /specification/ containing the contents of the lockfile from the first build. The test then checks that the build_id is different for each build job, that the lockfiles for both jobs are identical, and that the second job has the expected dependencies that were sent as part of the first build job.
The problem is that the function that actually builds the environment, conda_store_server._internal.worker.build.build_conda_environment, produces lockfiles in two different ways:
If the build is created using a specification that just contains an environment with dependencies, conda-lock is used to solve the environment and write the lockfile, inside conda_store_server._internal.action.generate_lockfile.action_solve_lockfile
If the build is created using a specification that is really just a pre-existing lockfile, schema.LockfileSpecification is used to parse the lockfile, inside conda_store_server._internal.worker.build.build_conda_environment.
When this test runs, the two different lockfile specifications don't match because they can't - schema.LockfileSpecification is a pydantic model that is part of conda-store, and the other is whatever conda-lock spits out.
Expected behavior
We should probably validate the output of conda-lock inside action_solve_lockfile so that the lockfile spec produced matches the model that we use to parse and save it later on in subsequent builds.
Describe the bug
There's a bug in
test_create_lockfile_specification_auth. This test sends a POST to/specification/which initiates a build; then it grabs the resulting lockfile produced by the build, and sends another POST to/specification/containing the contents of the lockfile from the first build. The test then checks that thebuild_idis different for each build job, that the lockfiles for both jobs are identical, and that the second job has the expected dependencies that were sent as part of the first build job.The problem is that the function that actually builds the environment,
conda_store_server._internal.worker.build.build_conda_environment, produces lockfiles in two different ways:conda-lockis used to solve the environment and write the lockfile, insideconda_store_server._internal.action.generate_lockfile.action_solve_lockfileschema.LockfileSpecificationis used to parse the lockfile, insideconda_store_server._internal.worker.build.build_conda_environment.When this test runs, the two different lockfile specifications don't match because they can't -
schema.LockfileSpecificationis a pydantic model that is part ofconda-store, and the other is whateverconda-lockspits out.Expected behavior
We should probably validate the output of
conda-lockinsideaction_solve_lockfileso that the lockfile spec produced matches the model that we use to parse and save it later on in subsequent builds.How to Reproduce the problem?
Run
test_create_lockfile_specification_auth.Output
No response
Versions and dependencies used.
No response
Anything else?
No response