Add opa to $PATH in docker image

[matusf]

What is the underlying problem you're trying to solve?

When running opa in the CI one needs to find out where is located. For example my current gitlab ci looks like this. I needed run the image and find that it is located at root. If it was is $PATH, one would not have to do this.

test_policies:
  image: openpolicyagent/opa:0.43.0-debug
  script:
    - /opa test .

Describe the ideal solution

Opa binary could be added to $PATH.

[philipaconrad]

Do you think this issue could have been solved with better documentation, instead of a Dockerfile change?

[anderseknert]

This seems like a Gitlab issue if anything. The image already points out the command/entry point, so why does this need to be repeated in the script? I would expect there to be an “args” parameter to the image one where the sub command plus extra arguments were provided, but not that the location of the OPA binary 🤔

[anderseknert]

That said - if that isn’t the case, and changing this helps to run OPA in that environment, I’m all in favor. I wonder though if there could be any tooling depending on the location, and changing that would break things outside of the project.

[matusf]

@philipaconrad, maybe it would help but I would not say it would solve the issue. When you are running the image in the CI, you expect the command that is the image about to be in the $PATH. Then it fails, and you try to seach for the solution. The docs would just make the search for the solution smaller.

@anderseknert, I don't know. Maybe, I guess it's just matter of preference. The Gitlab CI works by dropping you in a shell and you can run anything from it. The nice thing is, that it is universal. You do not need to create special structure for a command like in Github CI. Anyway, It is possible to override entrypont, but every job needs an script section.

As for the breaking change, a sym-link could be made not to break the compatibility, but I don't know if someone depends on the binary location.

[srenatus]

As for the breaking change, a sym-link could be made not to break the compatibility, but I don't know if someone depends on the binary location.

It's possible that someone building a container image of using COPY --from ... /opa to get the binary from the image into a new one. So if a symlink works here, too, I think that would be preferable.