Issues creating a file using withNewFile

[stuck robin]

I am building a Dagger module leveraging AI through LangChain to generate unit tests for a Sveltekit project. As part of this, I want to create a “tests” folder and a file “Home.test.ts” within the tests folder.

Currently, I am creating a tests folder at the root level of the working directory.
const tempDir = await root.withNewDirectory("/tests");

I attempt to create a new file within the tests folder:
const testFile = await root.withNewFile("/tests/Home.test.ts", "")

I mount this directory:
.withMountedDirectory("/mnt", tempDir)

However when I inspect the structure of the directory I don’t see the Home.test.ts file;
✔ exec tree /mnt 0.9s
┃ ├── routes
┃ │ ├── +page.svelte
┃ ├── setupTests.ts
┃ └── tests

I’ve tried a few things;

1. I noticed tests is read only, I tried to change permissions to make it read and write before creating the new file within this folder:
   "chmod", "775", "/mnt/tests"]
2. I tried creating the file within routes without creating a tests folder
3. I tried running using shell scripts to create a directory and then create a file within the directory

As a side question:
I noticed that even when I mount my working directory to the Dagger container, the changes I make within Dagger are only within the container and not synchronized locally. After reading one of your GitHub issues answer I realized WithMountedDirectory isn’t bind mounting the files in my machine to the build
link:https://github.com/dagger/dagger/discussions/6688

I had initially built this module outside of Dagger to create the files and folders for my tests in my directory. I assume if I cannot replicate this behavior with Dagger, I could create a Docker image of the container. Any thoughts on this?

[jolly siren]

For your main question, it looks like you probably wanted to mount testFile and not testDir here .withMountedDirectory("/mnt", tempDir). Side note, I don't believe any of those operations needed await

I had initially built this module outside of Dagger to create the files and folders for my tests in my directory
Yeah since there's no way to bind mount (today), the best bet would be to export the resulting new files back to the host. One example of this (sorry its for the Go ecosystem so it might not be obvious why it's the same) is this go generate function https://github.com/vito/daggerverse/blob/f7223d2d82fb91622cbb7954177388d995a98d59/go/main.go#L241-L247

[stuck robin]

I used the export method to write ‘the contents of the directory to a path on the host’. I assume this means the directory should be visible locally in the path defined in exportPath, yet the file isn’t available. Am I misunderstanding what export does?

` const tempDir = root.withNewDirectory("/tests");
const testFile = tempDir.withNewFile("/tests/Home.test.ts", "")

// Mounting directory to container
const container = dag.container()
.from("alpine:latest")
.withMountedDirectory("/mnt", testFile)
.withWorkdir("/mnt")

 const finalPath = "/Users/EmmS21/Desktop/PersonalWork"
 return this.exportUpdatedDirectory(tempDir, finalPath);

@func()
async exportUpdatedDirectory(updatedDir: Directory, exportPath: string): Promise<string> {
const success = await updatedDir.export(exportPath);
if (success) {
let successMessage = Successfully exported directory to ${exportPath};
return successMessage;
} else {
throw new Error(Failed to export directory to ${exportPath});
}
}`

[jolly siren]

Kind of! See https://docs.dagger.io/manuals/user/620164/host-fs
When you call export inside your module, you're exporting to the module's container, which is not your host. What you want to do is export from the function call.

So if your function returns a Directory, and you call something like
dagger call generate-tests <args>, you would instead call
dagger call generate-tests <args> export --path . or
dagger call generate-tests <args> --output .

[stuck robin]

Out of curiosity what are the barriers to enabling the container to interact directly with the host?

[spice relic]

Please don't use the return of .export. You need to handle the error that may come from it instead (try/catch). It's always going to be true or raise an exception. We're planning on changing that return so your code will break in a future release.