chore: setup envoy_api MODULE#41907
Conversation
mmorel-35
force-pushed
the
modules/envoy_api
branch
5 times, most recently
from
0da6e29 to
b7f6a9f
Compare
|
/retest |
|
@phlax , I confirm, retest command is properly working |
mmorel-35
force-pushed
the
modules/envoy_api
branch
from
45f5b11 to
abe1a02
Compare
|
@phlax , Once this is merged, There only be ci parts to merge in envoyproxy/data-plane-api#632 |
mmorel-35
force-pushed
the
modules/envoy_api
branch
4 times, most recently
from
ebd76ca to
0ea7138
Compare
|
I provided bcr config but it won't be operational until the publish.yaml workflow is setup |
mmorel-35
force-pushed
the
modules/envoy_api
branch
from
0ea7138 to
9f7bdc0
Compare
mmorel-35
changed the title
|
@phlax , The first version of envoy_api MODULE is ready for review. |
phlax
left a comment
phlax
left a comment
There was a problem hiding this comment.
really nice work, thanks @mmorel-35 - a couple of nits, questions, comments, etc
| - "@envoy_api//tools/..." | ||
| build_flags: | ||
| - "--java_runtime_version=remotejdk_21" | ||
| - '--cxxopt=-std=c++17' |
There was a problem hiding this comment.
nit: my pref is " but either way lets keep it consistent
| @@ -0,0 +1,102 @@ | |||
| module( | |||
| name = "envoy_api", | |||
| version = "1.37.0-dev", | |||
There was a problem hiding this comment.
i guess no way to have it read from the VERSION.txt ? this will need to be added to ci to ensure its not out of sync etc, and gets updated on releases
There was a problem hiding this comment.
It will be overriden by publish workflow anyway but it needs to be statically defined yes
There was a problem hiding this comment.
k - probs we should open a ticket to make sure the release/ci tooling has this added
| !\.zuul.yaml | ||
|
|
||
| /bazel-* | ||
| MODULE.bazel.lock |
There was a problem hiding this comment.
i still dont understand why you dont commit bazel lock files
There was a problem hiding this comment.
I'll commit it if you prefer
There was a problem hiding this comment.
not sure on current wisdom with this - so ill defer to whatever you think best - but i would have thought hashes were needed to ensure reproducible builds
There was a problem hiding this comment.
Let's try with it first, we'll see how it goes ;)
There was a problem hiding this comment.
maybe im thinking about it wrong - im thinking in terms of us consuming/building/testing the code (so i guess envoy will eventually commit its lockfile including api etc) - whereas this is more about publishing to bcr - probs we will need to adjust the gitignore at some point i guess
…nagement Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
mmorel-35
force-pushed
the
modules/envoy_api
branch
from
9f7bdc0 to
61625c2
Compare
|
@phlax , CI is happy with all that, I believe it's better to merge this one before the gitignore PR |
| "homepage": "https://www.envoyproxy.io/", | ||
| "maintainers": [ | ||
| { | ||
| "github": "mering", |
There was a problem hiding this comment.
@mering ill land this for now but wanted to confirm you are happy being listed as a bcr maintainer
we have an envoy-bzlmod channel on the envoy slack - would you be able to jump on there if so?
Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com> Signed-off-by: Gustavo <grnmeira@gmail.com>
2 participants
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]