expose bundle build args

[srenatus]

Currently, there is no way to influence how a bundle gets build, like you can with opa build. Optimization levels are a something that people might want to control. If O=1 and O=2 are exposed, we'll also need to expose the inlining control settings. It should also be possible to build plan or wasm bundles.

It could be a new options field that's per-bundle, in both the config and the HTTP handlers.

📝 Laundry list

• optimization
• v0/v1
• capabilities
• revision bundles: configurable revisions #268
• target (plan/IR, wasm, rego) bundle: add configurable target (default: "rego", also "ir" and "wasm") #220

[mefarazath]

In our system, we are considering to use a revision set by our CI/CD system as the bundle revision during the build.
So if this is possible via a build arg or as part of the bundle configuration it would be really useful

[srenatus]

@mefarazath I've split off the revision bits and implemented them in #268. Could you have a look if it would cover your use case? 😃

[mefarazath]

@mefarazath I've split off the revision bits and implemented them in #268. Could you have a look if it would cover your use case? 😃

Options:1 Just a string, revision: '"my-bundle-revision-1"',

this should cover our case. We have a build-number from our CI/CD system which we would most probably use as the revision.

And i love the rego query option too :)

If i am not wrong that would allow us to do interesting things like dynamically generating a values as revision (based on say a static_value (like our build-number) plus the git commit )

[srenatus]

And i love the rego query option too :)

As it stands, it'll always go through rego. Which is why the string needs to be double-quoted, which is a bit obnoxious, but I think it nicely streamlines the UX. It'll mean we can experiment with all the revision options from opa eval...

If i am not wrong that would allow us to do interesting things like dynamically generating a values as revision (based on say a static_value (like our build-number) plus the git commit )

Exactly, using a string template like

revision: $"rev-{input.sources["some-git-source"].git.commit}-{opa.runtime().env.BUILD_ID}"

[srenatus]

Revision is done. The latest :edge build should already include the feature. If you'd like to play with it before I wrap it into a release that would be appreciated! 🎉