I'm on the fence on whether I should file a bug. U...
# general
b
I'm on the fence on whether I should file a bug. Upgrading to Pants 2.17.x made 4 (out of 500) tests fail in our repo. The test performs some SQL operations on a DB stored in-repo as part of the test. Now we're getting
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) attempt to write a readonly database
because the file is a Read-Only hardlink from the "large file store". I think whether its a bug or not depends on the kind of guarantee we give about the state of the sandbox. I'm leaning "not a bug, but certainly a quirk". Thoughts?
c
how did the large file get into the store?
if you have a
test.db
file in your repo for instance, and that is pulled into the test sandbox as a
resource
for instance, I would expect it to be writable, in the sandbox, but not reflected in the repo after.
b
How would we know what should be writable or not? And besides, aren't resources expected to be embedded in artifacts?
c
ok, as a
file
then..
b
😛
c
the point was merely were it came from
b
How would we know what should be writable or not?
I guess you're saying we should not do the hardlinking if the source of the digest was in-repo? Hmmmm
c
I’m not saying nothin’ yet.. 😅 but I may end up there, yes
b
Obligatory: "What does Bazel do?"
🙊 1
😆 1
c
actually, I think I would expect any file in the sandbox be writable, because, sandbox I should be free to do whatever without consequence within it. But then I guess hardlinking won’t ever work, so that is a trade-off, if you want perf you need to give up writability, but maybe this is a toggle you should be able to flip on a case by case basis?