-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Charles/eopa engine #1000
Charles/eopa engine #1000
Conversation
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 so far 👍
build/do.rq
Outdated
# similar setups locally. Setting GIT_CONFIG=/dev/null in this case | ||
# prevents this. | ||
|
||
fetch_cmd := rq.template("sh -c 'GIT_CONFIG=/dev/null git archive --remote={{.remote | quote}} {{.ref}} {{.srcdir | quote}} | tar -x -C {{.destdir | quote}}'", templ) |
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.
No idea what's preferable, but if you'd consider it less of a hassle, you could grab the zip:
https://github.com/StyraInc/enterprise-opa/archive/refs/heads/main.zip
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.
I was trying to find a good way to only have to download the subset of the repo that is needed, rather than the entire thing. If all else fails, I'll just do that, and/or clone the whole repo into /tmp
or something.
I don't know why the git archive
thing doesn't work. StackOverflow says it should. The man page leads me to believe it should. But run()
is complaining about a mismatched '
, and on top of that when I run it manually, git
complains about trying to clone a git://
URL with the ssh://
protocol, which is just bizarre.
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 good! Just some minor remarks. There were other changes in the past though that I'm curious to know more about. Were they not needed?
build/do.rq
Outdated
|
||
{ rq.error(sprintf("\nstdout: %s\nstderr: %s\n", [eopa_tags_result.stdout, eopa_tags_result.stderr])) | eopa_tags_result.exitcode != 0 } | ||
|
||
eopa_tags := {r[2] | r := eopa_tags_result.stdout[_]} |
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.
Can we use some ... in
iteration instead? Here and on line 257. This file isn't lintable at this point in time, as we'd need something similar for rq
as this PR provides for eopa
. But that doesn't mean should ignore the best practices and idioms Regal recommends.
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.
I'm not actually sure how to use some ... in
, can that handle additional clauses? I ended up having to filter the tag list down with further clauses.
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.
hmm, yeah after 646a37d I'm not sure some ... in
can work, based on reading the docs
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.
It works anywhere:
eopa_tags := {t | some r in eopa_tags_result.stdout; t := r[2] ; not known_bad_tags[t]}
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.
Ahh I see, I didn't realize you could use it in that way. I'll switch it over.
b6d2f9e
to
34b26a9
Compare
e1d4aed
to
ec8c3a6
Compare
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.
Great work on this!
I left a couple of comments. You can ignore the style-related ones if you wish, as Regal itself will tend to most of them once we can lint .rq files :)
The rest should be considered however.
Very nice contribution!
Still needs some refactoring, but we can properly use the embedded capabilities in the LSP now.
Rather than using an option, we upgrade the existing rego package so that the builtins can be updated at runtime.
We have the capabilities embedded into Regal now instead.
We want the regal:// URI scheme to be a hidden implementation detail.
Moving the rq.write() to the LHS of the | seems more intuitive, and it avoids the possibility that OPA may one day optimize comprehensions with constants on the LHS.
The CI indicates that this is not allowed.
b5cb5c5
to
e893548
Compare
I'm not sure why the tests are suddenly failing in CI? They pass on my machine, and none of the code the failing tests exercise was changed since the last commit where they passed. I think |
Interestingly, I do see a similar test failure when I run in an Alpine docker container (ARM64). This smells like some concurrency problem to me. |
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.
Thanks a lot for this Charles! I'll merge this as it is, and will have a look at the build issues reported when merged.
And extend capabilities to allow fetching from remote URLs.
And extend capabilities to allow fetching from remote URLs.
This PR adds initial support for an EOPA engine. It depends on the upstream PR #92, and should not be merged before that one is.
It includes 3 main components:
config
package has been changed so that if theeopa
engine is used, the new helpers in the upstream PR are used to look up the capabilities that are attached to theconfig.Config
type. The engine and version are saved in the config for later use.internal/lsp
package has been modified to inspect the engine and version from the configuration, and to look up capabilities for use in theinternal/lsp/rego
package.capabilities
package has been added to provide a general-purpose way for Regal to access OPA capabilities. It unifies access to local, remote, and embedded capabilities using URLs. Bothconfig
andinternal/lsp
have been refactored to use this new system.In summary,
capabilities.Lookup()
supports loading OPA capabilities in the following ways:file://
URLs are loaded as JSON from disk, just like specifyingfrom.file
.regal:///capabilities/default
loads the capabilities usingast.CapabilitiesForThisVersion()
regal:///capabilities/{engine}
loads the latest (according to SemVer) capabilities version for the engineregal:///capabilities/{engine}/{version}
loads the specified capabilities version for the engineSemantic versioning support is implemented using
github.com/coreos/go-semver/semver
, which is the same library OPA uses for its semver builtins.The existing
from.engine
,from.file
, andfrom.version
will continue to work, but internally they are translated to URLs so that access to capabilities is consistent everywhere in Regal.from.url
has been added as well.These changes do appear to work, and enable Enterprise OPA specific builtins to appear in the VSCode plugin with only a config change.
Remaining work:
capabilities.Lookup
functionalityrego
package