Allow setting OPA_VERSION_CHECK_SERVICE_URL=false

[folliehiyuki]

Why the changes in this PR are needed?

This PR provides a simple way to disable version check entirely. It's useful for downstream distribution of the opa binary (e.g. Linux distros). We don't want users to go download the newer version on GitHub into their system PATH like /usr/bin when being noticed of an update.

Notes to assist PR review:

With this commit, opa version -c command errors out, and opa run fails the check silently in the background. I don't know whether the approach is appropriate, but it produces the simplest patch.

[netlify]

✅ Deploy Preview for openpolicyagent ready!

Name	Link
🔨 Latest commit	afabd8e
🔍 Latest deploy log	https://app.netlify.com/projects/openpolicyagent/deploys/69ac48ba7eb315000881dd28
😎 Deploy Preview	https://deploy-preview-8411--openpolicyagent.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[anderseknert]

The rationale makes sense to me. I think I'd prefer it if we used a (new) boolean property for the on/off toggle, but I don't think I even saw this code before, so I'll wait to see what others think here 😅

[srenatus]

Thanks for contributing. I've got a couple of questions:

1. How would the distribution set the env var so that every invocation of opa would have it set? With a wrapper script? It feels to me like a build tag would be a better solution, perhaps.
2. Is there an actual distribution interest behind this? Do you manage an OPA package for some distribution, by any chance?

Thank you!

[charlieegan3]

We don't want users to go download the newer version on GitHub into their system PATH like /usr/bin when being noticed of an update.

I am interested by this, there is no auto update logic, just notification of newer versions. This can be disabled with --skip-version-check. We do provide a link to the static binary, but we also link to the release notes. There are not prompts encouraging immediate installation.

Please also note that while we do allow OPA to be packaged, the only officially supported means of installation on Linux is from our release binaries and container images. (https://www.openpolicyagent.org/docs?current-os=linux#1-download-opa)

[anderseknert]

Since we allow pointing the URL somewhere else than that officially supported location, I find it hard to see why it shouldn’t be possible to disable entirely.

[anderseknert]

@srenatus this already involves a build tag, no? The distro would not need to set any env var but just build with that flag set to modify the URL (or whatever) stored in the package level var.

[srenatus]

@srenatus this already involves a build tag, no? The distro would not need to set any env var but just build with that flag set to modify the URL (or whatever) stored in the package level var.

Builds tags != ldflags. I think yeah, you should be able to override the URL via ldflags, and perhaps have a check that sees if the URL is valid, and disables the lookup if it is.

[srenatus]

I think something like regal has would make sense, like a build tag (actual tag), opa_standalone, which would be enabled on "official builds", and enables this version check (among potentially other things in the future), whereas if you don't build with that tag, the version check would just not happen.

On a related note, I like tools that report how they were installed in <tool> version. Like, source: homebrew or source: github or something. 💭 Always makes it easier to remember how a things is to be upgraded. (I mean, it doesn't get us much, which opa is usually doing the trick just as well...)

[srenatus]

Thinking about it, we should make a certain Makefile target the canonical entrypoint for distributions to use to build an OPA binary. That way, we can update the concrete mechanism later without requiring all the distributions to update their scripts. I'd hate to have our ldflags leak into every definition.... What do you think, @folliehiyuki, from a distro perspective?

[anderseknert]

@srenatus build tag or build flag matters little compared to build time vs runtime, which my message was in response to:

How would the distribution set the env var so that every invocation of opa would have it set? With a wrapper script?

Unless the submitter answers your questions, I don’t think there’s much to do but close here though.

[folliehiyuki]

How would the distribution set the env var so that every invocation of opa would have it set? With a wrapper script? It feels to me like a build tag would be a better solution, perhaps.

At the moment, we simply inject an invalid HTTP endpoint into the ExternalServiceURL variable through -ldflags at build time. I intentionally put the change in this PR below the url == "" condition. That way, if the user doesn't set the environment variable, the variable set at build time still takes effect. Getting invalid HTTP endpoint by default is a bit confusing though.

Is there an actual distribution interest behind this? Do you manage an OPA package for some distribution, by any chance?

Yes, I'm the maintainer of opa package for Alpine Linux. I also use NixOS, so if this PR lands in a way or another, I can send an update to open-policy-agent package in Nixpkgs as well.

I am interested by this, there is no auto update logic, just notification of newer versions. This can be disabled with --skip-version-check. We do provide a link to the static binary, but we also link to the release notes. There are not prompts encouraging immediate installation.

I'd like the version check to happen only when a user runs opa version -c, and nowhere else like opa run. Letting the user be aware that the binary is outdated is nice, but the GitHub link information is practically useless if they use the binary provided by a 3rd party like a Linux distro. The preferable way is to notify the package maintainer of the distro to update the package.

On a related note, I like tools that report how they were installed in version. Like, source: homebrew or source: github or something. 💭 Always makes it easier to remember how a things is to be upgraded. (I mean, it doesn't get us much, which opa is usually doing the trick just as well...)

I assume every distribution does this (Alpine Linux does for a lot of Go packages). Injecting these specific information at build time is a also way to tell users of those packages to send bug reports / update notifications to us package maintainers first instead of the upstream code base on GitHub.

Thinking about it, we should make a certain Makefile target the canonical entrypoint for distributions to use to build an OPA binary. That way, we can update the concrete mechanism later without requiring all the distributions to update their scripts. I'd hate to have our ldflags leak into every definition....

👍

Please note that each distribution builds the same Go package differently. For example, in Alpine Linux, all Go packages are built with -buildmode=pie, non-static along with a few other flags. Creating a generic make target to satisfies different use cases might be a bit challenging. We packagers do read the release changelogs, so if you document the -ldflags changes effectively, that would be helpful enough.

I think something like regal has would make sense, like a build tag (actual tag), opa_standalone, which would be enabled on "official builds", and enables this version check (among potentially other things in the future), whereas if you don't build with that tag, the version check would just not happen.

I'm fine with any approaches, but I prefer that the mechanism can be utilized by both the users at runtime and the package providers at build time.

With that said, I can go back to this PR this weekend. Until then, feel free to provide more info and point me to a right direction for the final implementation.

[charlieegan3]

@folliehiyuki, thanks for taking the time to respond here in such detail. Let's get this working in a way that works for you.

It seems that package repos build things their own way E.g.

• https://github.com/wolfi-dev/os/blob/main/opa.yaml#L39
• https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/op/open-policy-agent/package.nix#L15

So I think a build tag might be the best foundation for this, but we might also add a make target for this option in case the list of things we need to do in future grows beyond a single build tag.

What about packagemanaged as the name for the tag?

[srenatus]

Yes, I'm the maintainer of opa package for Alpine Linux.

👏 I think it's great that there's an opa package in aports. Thanks a bunch for your work on this 🎉

[folliehiyuki]

So I think a build tag might be the best foundation for this, but we might also add a make target for this option in case the list of things we need to do in future grows beyond a single build tag.

What about packagemanaged as the name for the tag?

Seems fine to me. I don't have an idea how to implement the build tag approach at the moment, so let me look into it a bit more next week.

From @anderseknert 's note, should I also add an environment variable, that the user can utilize with the default release? Would OPA_DISABLE_VERSION_CHECK look okay?