#So.. hmm, given a Directory, is there a

1 messages · Page 1 of 1 (latest)

feral pumice
#

My directory layout is as below:

/                           # Root of git workspace
├── cmd
│   ├── opensearch-reindex  # Here's where I run 'dagger call ...'
│   │   ├── dagger          #  (in order to build 'opensearch-reindex' image)
│   │   │   └── main.go
│   │   ├── dagger.json
│   │   ├── main.go
│   │   ...
│   ...
├── dagger
│   └── main.go
├── dagger.json
├── go.mod                  # File to include in the build
├── go.sum                  # File to include in the build
├── lib                     # Directory to include in the build
│   ├── db
│   │   └── db.go
│   ...
...

Within my build I first need to copy /go.mod and /go.sum, as well as the /lib direcory, into the build environment. Then I want to copy the contents of /cmd/opensearch-reindex into the same relative path in the build environment, too, and use the name of the directory as part of the image name.

I found that I could just add some optional args with defaults to catch the "outside" dependencies, so that part seems to be solved.. and I could potentially just include the root (/) if I care to set up ignore patterns properly, but it would impact caching with things that aren't required for this specific build, so I'm not sure there.

    // +optional
    // +defaultPath="/go.mod"
    goMod *dagger.File,
    // +optional
    // +defaultPath="/go.sum"
    goSum *dagger.File,
    // +optional
    // +defaultPath="/lib"
    lib *dagger.Directory,
quiet badger
#

@feral pumice is the idea to keep your pipeline generic enough so --dir could be something else than cmd/opensearch-reindex? As otherwise for this particular case you can just hardcode the path and that's it.

#

I guess a better approach here is to move to your dagger.json to the top of your repo and change the source value to point to your ./cmd/opensearc-reindex folder.

this way you can do: dagger call what-is-my-relative-path --dir=cmd/opensearch-reindex and in that case the Name function will return the right path

#

it seems a bit strange that the dagger.json is already within the ./cmd/opensearch-reinde dir but you're expecting the --dir flag to get the relative path to that directory when you can just hard-code it for this module?

feral pumice
#

Well, cmd/opensearch-reindex is just one of many CLI tools and services in this repo.. I suppose that I can add a hard-coded path within cmd/opensearch-reindex/dagger/main.go, I had just hoped not to have to specify something that was already implicitly defined 😅

My ultimate goal is really to make sure that if I'm working on this specific component, I can be in cmd/opensearch-reindex, edit my Go code, do some test runs with go test, go run, etc, and then just run dagger call deploy --env=test if I want to deploy that specific component to a test environment.

At the same time I want to be able to have a top-level flow in the repo where I can be at / , and run for example dagger call deploy --env=prod --component=cmd/opensearch-reindex, or run dagger deploy-all --env=prod and it will loop over all CLIs in cmd/ and all services in services/, building them and deploying as needed.

quiet badger
# feral pumice FWIW, my intention was to follow the suggested pattern here, option (1): https:...

gotcha.. I guess it really depends on how you structure your monorepo.

i.e: for what I'm undertsanding here you have a structure similar to the following:

/  > global repo, multiple packages used by different CLI's
/cmd/cl1
/cmd/cli2
/cmd/cliN

^ that's one type of mono-repo structure depending on how you see that. A different structure could be

/
/app1/cmd/cli1
/app2/cmd/cli1
/appN/cmd/cliN

where each CLI has its own folder and is its own go module by itself.

For the first example, which I understand is the one you have, it could be more convenient to have a single module at the root of the repo with functions like CLI1 CLI2, CLIN that build and return each CLI instead of having one module per CLI

#

I'm mostly brining this up based on my experience and how I generally see different teams structuring go apps. The one Dagger module per monorepo app model works best when each app has its own set of dependencies and it's clearly separated from the others. In the context of Go's /cmd/$cli pattern, I generally find it best to only have one module to build the different CLI's as they're genreally part of a single global go module