Can't build the same charm in parallel
Metadata
Current evaluation
Closed without a confirmed code fix after the reporter did not clarify the parallel-build setup; maintainers linked the behavior to #103.
Resolution: closed stale
Reason: On 2021-01-12, facundobatista closed the report for lack of information after the reporter did not answer the clarification request. No resolving PR or commit was identified; maintainers said related behavior had recently changed and pointed to #103.
Evaluated by: mr-cal-bot
No scores available.
Issue body
If I'm building one charm on the same machine in different processes, one of the builds will fail due to each charmcraft build process using the same build directory, and removing it after it's done. The traceback that I get:
```python
Traceback (most recent call last):
File "/snap/charmcraft/97/lib/charmcraft/main.py", line 191, in main
dispatcher.run()
File "/snap/charmcraft/97/lib/charmcraft/main.py", line 121, in run
command.run(self.parsed_args)
File "/snap/charmcraft/97/lib/charmcraft/commands/build.py", line 390, in run
builder.run()
File "/snap/charmcraft/97/lib/charmcraft/commands/build.py", line 105, in run
shutil.rmtree(str(self.buildpath))
File "/usr/lib/python3.8/shutil.py", line 715, in rmtree
_rmtree_safe_fd(fd, path, onerror)
File "/usr/lib/python3.8/shutil.py", line 652, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
File "/usr/lib/python3.8/shutil.py", line 652, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
File "/usr/lib/python3.8/shutil.py", line 652, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
File "/usr/lib/python3.8/shutil.py", line 672, in _rmtree_safe_fd
onerror(os.unlink, fullname, sys.exc_info())
File "/usr/lib/python3.8/shutil.py", line 670, in _rmtree_safe_fd
os.unlink(entry.name, dir_fd=topfd)
FileNotFoundError: [Errno 2] No such file or directory: 'namedtype.py'
```
Since `charmcraft build` results in a `*.charm` file dropped in the current directory, instead of a directory that users need to interact with, it seems like we could just use `tempfile.TemporaryDirectory` instead of basing the build directory on the charm name.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha | — | closed stale | Closed without a confirmed code fix after the reporter did not clarify the parallel-build setup; maintainers linked the behavior to #103. | |
| stealth/space-bunny-alpha | — | closed superseded | Closed as a duplicate of charmcraft#103 after related build-directory behavior changed; no parallel-build-specific fix was made here. | |
| stealth/space-bunny-alpha | — | closed superseded | Closed as a duplicate of #103 after build-directory handling changed; the maintainer later closed it for lack of information. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Closed as a duplicate of issue #103 after build directory handling was updated. The parallel build race condition was reportedly addressed, but the issue was ultimately closed due to lack of follow-up information from the reporter. | |
| qwen/qwen3.6-35b-a3b | — | — | Closed due to lack of response. Maintainers noted parallel build conflicts were addressed in issue #103. Without further use case clarification, the report was abandoned. | |
| qwen/qwen3.6-35b-a3b | — | — | Closed as duplicate and abandoned due to lack of information. The parallel build conflict was reportedly resolved via behavioral changes in issue #103. No direct fix applied. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Closed due to lack of information. The parallel build conflict was superseded by issue #103, which updated build directory handling. No fix applied to this report. |
Update history
No update history recorded yet.
Related work
-
Duplicate Of:
canonical/charmcraft#103
(confidence 85%)
The maintainer described #103 as addressing very similar build-directory behavior.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1845 Building multiple charms simultaneously can cause caching errors | charmcraft | closed | Parallel charm builds were fixed by merged PR #1888 (commit 4cce11b0), which locks the shared cache to prevent concurrent builds from reusing incomplete files. |