Fix docker/podman discovery script for podman-compose. #96
Conversation
|
Can one of the admins verify this patch? |
spicedb/check_docker_podman.sh
Outdated
| if command_exists docker-compose; then | ||
| echo "docker-compose is installed." | ||
| else | ||
| echo "docker-compose not found. Please install either docker-compose or podman-compose to proceed." | ||
| exit 1 | ||
|
|
There was a problem hiding this comment.
This update will only echo only.
Script: https://github.com/project-kessel/relations-api/blob/main/spicedb/start-insights-rebac.sh#L6
continue to use docker compose as the default compose tool.
Newer version of docker-compose follows: docker compose vs docker-compose. I think Will had issue on linux for docker-compose.
There was a problem hiding this comment.
Add export COMPOSE=docker-compose or export COMPOSE=podman-compose
Update the https://github.com/project-kessel/relations-api/blob/main/spicedb/start-insights-rebac.sh#L6 to use the COMPOSE var
There was a problem hiding this comment.
Yeah, it's inconsistent as it is. It checks for docker-compose and podman-compose, but actually uses "docker compose" or "podman compose" in the scripts.
The hyphen format is obsolete (https://stackoverflow.com/questions/66514436/difference-between-docker-compose-and-docker-compose/66526176#66526176), so we can either assume that compose is directly included with docker/podman in the versions that users are using these days, or we can do some version detection on docker and fall back to the hyphen version.
Personally, I'm inclined to do the minimal thing, and just remove the compose checks from the above script. Wdyt?
(As you say, the checks don't set a var, just warn you if you don't have a compose command. And in fact, the check could be wrong in the future when the hyphen versions are no longer supported in installs.)
There was a problem hiding this comment.
yes, remove them would make sense.
PR Template:
Describe your changes
Ticket reference (if applicable)
Fixes #
Checklist
Are the agreed upon acceptance criteria fulfilled?
Was the 4-eye-principle applied? (async PR review, pairing, ensembling)
Do your changes have passing automated tests and sufficient observability?
Are the work steps you introduced repeatable by others, either through automation or documentation?
The Changes were automatically built, tested, and - if needed, behind a feature flag - deployed to our production environment. (Please check this when the new deployment is done and you could verify it.)
Are the agreed upon coding/architectural practices applied?
Are security needs fullfilled? (e.g. no internal URL)
Is the corresponding Ticket in the right state? (should be on "review" now, put to done when this change made it to production)
For changes to the public API / code dependencies: Was the whole team (or a sufficient amount of ppl) able to review?