-
Notifications
You must be signed in to change notification settings - Fork 0
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
chore: update documentation for local setup for running cli commands #301
base: main
Are you sure you want to change the base?
Conversation
Added example for exetuting CLI API commands.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, few comments!
::: | ||
|
||
```sh | ||
docker exec -it \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about using docker compose
? Then it'll let you reference the friendly names of the containers.
docker compose exec -it api /bin/sh -c "..."
for example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That does mean your current directory needs to be vol-app right? Exiting solution would allow execution from anywhere; unless we prefix with a cd
or something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point, but I think documenting less flexible commands is far simpler to maintain for us. We could note that these commands need to be ran from the vol-app
root directory?
While it's incredibly minor, we don't control the vol-app-api-1
naming. For example, the separator changed recently from _
to -
in Docker Compose v2.
-e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \ | ||
-e AWS_SESSION_TOKEN=$AWS_SESSION_TOKEN \ | ||
vol-app-api-1 \ | ||
/bin/sh -c "HOME=/tmp php -d memory_limit=1024M /var/www/html/vendor/bin/laminas --container=config/container-cli.php list" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need HOME
, or a memory limit setting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at it, memory setting no as default is 2GB so thats okay. As for HOME, I believe that was done on the old environments because we force to be a /tmp dir (cleaned after reboots etc...). Some commands generate content.
This was largley just a tweak of the old way we used to do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, okay, I'd probably say it's best we remove both as it's not typical of the command we run on infrastructure. Your call.
-e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \ | ||
-e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \ | ||
-e AWS_SESSION_TOKEN=$AWS_SESSION_TOKEN \ | ||
vol-app-api-1 \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remember we have a CLI container for CLI jobs. This container uses the image that's used in AWS batch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see... Okay, I'll try and get it working with that.
Description
Added example for exetuting CLI API commands in local setup documentation.
Before submitting (or marking as "ready for review")