We currently have two redundant ways to test for breaking changes in
proto: proto-commit and releaselocks. These do the same thing, but add
substantial noise.
Release locks have also not been updated since 1.6.
The original intent was to test for breaking changes between versions.
However, since we test for breaking changes on each commit, there is no
need for the extra check; if it would have failed as "breaking change
from 1.0 -> HEAD" then it would also fail with "breaking change from
HEAD^ -> HEAD".
Finally, there are some weird LC_ALL issues with sorting that make the
releaselocks really hard to use, especially for newcomers. I spent hours
trying to fix it without success
* operator: use camelCase
operator relies on merging using K8s libraries. K8s libraries use the
`json` tag. protobuf doesn't have a way to configure this (`json_tag` is
for `protobuf.json`, not `json`) and never will.
JSON tag comes from the protobuf name. So we can make it camelCase to
fix the above issue. This will have no impact on unmarshalling with jsonpb -- which we use in
all cases aside from the merging -- any casing is allowed.
This may be a breaking change in the protobuf sense (but NOT to Istio
users), but it doesn't really matter as until last week the operator
protobuf was not a real protobuf at all and relied on `sed` to make it
into the shape we want. Therefor, its not possible someone depended on
the operator protobuf being protobuf-compatible.
* add comment
* gen
* extra line
* comment
* gen
https://docs.buf.build/
Buf is the successor to https://github.com/uber/prototool which we
already use for linting.
This dramatically simplifies our Makefiles, which are both extremely
complicated and have led to numerous bugs historically, such as
https://github.com/istio/api/issues/1678.
This will make changes to the generation much simpler as well. For
example, to migrate to gogo protobuf, we will just need to change `gogo`
-> `go` in one location, rather than trying to wrangle 500 lines of
Makefiles. Additionally, its quite a bit faster - the whole proto stuff
is done in <1s now.
Keeping the existing labels.go for now until the main code branch is migrated over to use the new variables.
Will also remove security.istio.io/tlsMode (which always was a label, not an annotation) from annotations once the main code branch is migrated over to the label variable.
* Add proto for analysis messages
* Add analysis protos to make system
* Better comments, clearer intention with code/name
* Move analysis to beta, add meta types
* update ValidationMessages to validation_messages
* more snake casing, hopefully doesnt break kubernetes compatibility
* try to get all generated files updated
* update gen conflicts after rebase
* move analysis back to alpha
* demote meta to v1alpha1
* remove remnants of beta apis
* resolve gen problems related to demotion
Co-authored-by: Clayton Pence <ctpence@google.com>
* Consolidate opeator API to one file to maintain field order
* Mirror Tolerations
* Remove json gen
* Rebuild
* Restore deepcopy
* Remove unneeded sed
* Rebuild
* Lint
* Update releaselocks
* Move deepcopy from autogenerated path
* Copyright banner
* Gofmt
We have a pretty nasty bug where fields with two names, eg
UnvalidatedValues, aren't getting unmarshaled properly in k8s clients
because we haven't set up jsonpb unmarshaling for the Operator. This
should solve it.
* Move operator API to separate dir
* Update linter settings
* Add make gen files
* Add values field to gateways
* Make gen
* Add enablement for gateways
* Remove CoreDNS from core components list
* Add RequestAuthetication API
* Address comments
* Make JWTHeader type to define header with prefix
* Revert go.sum
* Address more comments
* Add blank line to end of file
* Update JwtHeader field
* Rename JwtHeader to JWTHeader for consistency
* Update security/v1beta1/jwt.proto
Co-Authored-By: Sven Mawson <sven@google.com>
* Update make gen
* Regenerate file after rebase
* Update comment
* Rebase
* use field_behavior opiton for required fields
* modify makefile to replace import path for field_behavior
* generate after image update
* changes after comments from policy and telemetry team
* regen after changes
* update networking and rebase