Hello,
Maybe I missed it in the documentation, but I am unclear about what would happen if there were two jobs running concurrently that attempted to write files to the same “path” in a workspace persistence.
To be clear, I have a windows executor and a linux executor doing a C++ build. Both run simulatenously. Right now, windows takes much longer, so I feel like my risk is low. However, I am wondering if both jobs were to do “persist_to_workspace” at the same time for path “artifacts/”, what would happen? Is there any locking mechanism that would delay one job while the first job writes to it?
In my use case, the order they are written does not matter - it only matters that it works. The next job that runs joins the concurrency in order to utilize the artifacts produced by those two concurrent builds.
Thanks!
Bumping this post.
@circleci-community is there a document that explains the answer to my question, or can a developer help clarify?
Are you able to share a screengrab of your pipeline?
Looking at my own use case for a single workspace persistence and attaching in the following job.
I can see that attaching the workspace tells me the filename in which it’s downloading followed by the file size eg: workspaces/8b43ffd7-e8f1-4cd6-aa01-413112b14467/cd35cf40-6c48-4c2c-ad0d-ba6fa2e75aba/c8a36882-6498-4144-a764-eab81cadf183/0/110.tar.gz
- The first fragment
8b43ffd7-e8f1-4cd6-aa01-413112b14467 is the CIRCLE_PROJECT_ID
- The second fragment
cd35cf40-6c48-4c2c-ad0d-ba6fa2e75aba is the CIRCLE_WORKFLOW_WORKSPACE_ID
- The third fragment
c8a36882-6498-4144-a764-eab81cadf183 is the workflow job id.
You can match them up yourself checking your Task lifecycle and Preparing environment variables steps.
Are you able to run your pipeline and check on the job which attaches, which workspace is being included?