-
Notifications
You must be signed in to change notification settings - Fork 12
Add --project-name cli flag. Lazily load project name from flags, env, or compose file #599
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lionello
reviewed
Aug 1, 2024
to have two methods: LoadProject, and LoadProjectName
6c777ec
to
03ebdec
Compare
lionello
reviewed
Aug 7, 2024
lionello
reviewed
Aug 7, 2024
lionello
reviewed
Aug 7, 2024
jordanstephens
added a commit
that referenced
this pull request
Aug 29, 2024
Since #599, we already consider the COMPOSE_PROJECT_NAME env var when loading the project name, so this fallback is redundant. We also want to suggest using the --project-name flag instead of the env var.
jordanstephens
added a commit
that referenced
this pull request
Aug 29, 2024
Since #599, we already consider the COMPOSE_PROJECT_NAME env var when loading the project name, so this fallback is redundant. We also want to suggest using the --project-name flag instead of the env var.
jordanstephens
added a commit
that referenced
this pull request
Aug 29, 2024
Since #599, we already consider the COMPOSE_PROJECT_NAME env var when loading the project name, so this fallback is redundant. We also want to suggest using the --project-name flag instead of the env var.
lionello
pushed a commit
that referenced
this pull request
Aug 30, 2024
Since #599, we already consider the COMPOSE_PROJECT_NAME env var when loading the project name, so this fallback is redundant. We also want to suggest using the --project-name flag instead of the env var.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #586
This pull request aims to add support for running
defang compose
commands outside of the project's working directory by using the--project-name
CLI flag. In order to accomplish this, thecompose.Loader
has been refactored to accept aprojectName
and to avoid trying to read thecompose.yaml
file from disk unless absolutely necessary.Many commands do not require any project information aside from the name, so will not need to read the compose file if the project name is passed using this new flag.
The
compose.Loader
will keep a reference to the project name passed by--project-name
flag, or by theCOMPOSE_PROJECT_NAME
env var. If a project name has not been passed through the cli flag or environment, thecompose.Loader
will read thecompose.yaml
file from the path passed in with-f
or from the current working directory. Once the compose file has been read, thecompose.Loader
will keep a reference to it in memory to avoid reading it again.In order to implement this, I have removed some stateful attributes with values derived from the project name. I have replaced references to these attributes with function calls which ask the loader for the project name. This introduces a fair amount of churn into the diff since
compose.Loader.GetProjectName
can return an error and callers of these derived values may now need to handle these errors.TODO