[BUG] - test_create_lockfile_specification_auth compares two different lockfile specs

[peytondmurray]

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 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:

1. 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
2. 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.

How to Reproduce the problem?

Run test_create_lockfile_specification_auth.

Output

No response

Versions and dependencies used.

No response

Anything else?

No response

[soapy1]

Fixed by peytondmurray#6, which has been merged into #985. So, going to close this issue