Replies: 3 comments
-
This is just a technical issue. The use case make sense. It has to do with the fact that the path of the files reference is technically relative to the So basically what you would do containers: foo: {
build: {
dockerfile: "Dockerfile"
context: "../.."
}
files: "/foo": "CommonLibProject"
} Then in your |
Beta Was this translation helpful? Give feedback.
-
Hi, thanks very much for getting back to me. For us at least, setting eg |
Beta Was this translation helpful? Give feedback.
-
I think I was wrong on this. Allowing directory sync from any location might be nice, but perhaps isn't the acorn way. The "access projects elsewhere" example
Can instead be handled by nesting that project's own Acornfile:
And, "quick access to user config files during dev"
Should probably be handled with secrets
With the first example of being able to have the Acornfile somewhere other than the top-level. That's not so straightforward, but we can easily workwround by symlinking the Acornfile to the top-level with a project init script. So I'm going to close this as I have all the answers I need. Thank you for pointing me in the right direction. |
Beta Was this translation helpful? Give feedback.
-
Take the following local directory structure. Where Deployment and Service1 are git projects.
├── Repos
│ ├── ProjectA
│ │ ├── Deployment
│ │ │ ├── Acornfile.local
│ │ ├── Services
│ │ │ ├── Service1
│ │ │ │ ├── src
During local development, we would like to be able to do things like reference projects within the group.
or projects elsewhere in the /repo tree
or even something like ~/.npmrc
However, each of the above would be disallowed by (I think!) https://github.com/acorn-io/aml/blob/7aded86d1c3ec20d6bfe169880a44a5fc3a049da/schema/v1/app.cue#L168
So, my question: is there a reason for disallowing references outside of the project route or can the regex that validates directory paths be made less strict?
Beta Was this translation helpful? Give feedback.
All reactions