Skip to content

Commit c0ba923

Browse files
committed
bump(k8s): update openshift/kubernetes to get 1.32.1
1 parent 7251cee commit c0ba923

File tree

4,634 files changed

+158646
-274948
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

4,634 files changed

+158646
-274948
lines changed

go.mod

+124-123
Large diffs are not rendered by default.

go.sum

+196-356
Large diffs are not rendered by default.

vendor/cel.dev/expr/.bazelversion

+2
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
7.0.1
2+
# Keep this pinned version in parity with cel-go

vendor/cel.dev/expr/.gitattributes

+2
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
*.pb.go linguist-generated=true
2+
*.pb.go -diff -merge

vendor/cel.dev/expr/.gitignore

+2
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
bazel-*
2+
MODULE.bazel.lock

vendor/cel.dev/expr/BUILD.bazel

+34
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
load("@io_bazel_rules_go//go:def.bzl", "go_library")
2+
3+
package(default_visibility = ["//visibility:public"])
4+
5+
licenses(["notice"]) # Apache 2.0
6+
7+
go_library(
8+
name = "expr",
9+
srcs = [
10+
"checked.pb.go",
11+
"eval.pb.go",
12+
"explain.pb.go",
13+
"syntax.pb.go",
14+
"value.pb.go",
15+
],
16+
importpath = "cel.dev/expr",
17+
visibility = ["//visibility:public"],
18+
deps = [
19+
"@org_golang_google_genproto_googleapis_rpc//status:go_default_library",
20+
"@org_golang_google_protobuf//reflect/protoreflect",
21+
"@org_golang_google_protobuf//runtime/protoimpl",
22+
"@org_golang_google_protobuf//types/known/anypb",
23+
"@org_golang_google_protobuf//types/known/durationpb",
24+
"@org_golang_google_protobuf//types/known/emptypb",
25+
"@org_golang_google_protobuf//types/known/structpb",
26+
"@org_golang_google_protobuf//types/known/timestamppb",
27+
],
28+
)
29+
30+
alias(
31+
name = "go_default_library",
32+
actual = ":expr",
33+
visibility = ["//visibility:public"],
34+
)
+25
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
# Contributor Code of Conduct
2+
## Version 0.1.1 (adapted from 0.3b-angular)
3+
4+
As contributors and maintainers of the Common Expression Language
5+
(CEL) project, we pledge to respect everyone who contributes by
6+
posting issues, updating documentation, submitting pull requests,
7+
providing feedback in comments, and any other activities.
8+
9+
Communication through any of CEL's channels (GitHub, Gitter, IRC,
10+
mailing lists, Google+, Twitter, etc.) must be constructive and never
11+
resort to personal attacks, trolling, public or private harassment,
12+
insults, or other unprofessional conduct.
13+
14+
We promise to extend courtesy and respect to everyone involved in this
15+
project regardless of gender, gender identity, sexual orientation,
16+
disability, age, race, ethnicity, religion, or level of experience. We
17+
expect anyone contributing to the project to do the same.
18+
19+
If any member of the community violates this code of conduct, the
20+
maintainers of the CEL project may take action, removing issues,
21+
comments, and PRs or blocking accounts as deemed appropriate.
22+
23+
If you are subject to or witness unacceptable behavior, or have any
24+
other concerns, please email us at
25+

vendor/cel.dev/expr/CONTRIBUTING.md

+32
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
# How to Contribute
2+
3+
We'd love to accept your patches and contributions to this project. There are a
4+
few guidelines you need to follow.
5+
6+
## Contributor License Agreement
7+
8+
Contributions to this project must be accompanied by a Contributor License
9+
Agreement. You (or your employer) retain the copyright to your contribution,
10+
this simply gives us permission to use and redistribute your contributions as
11+
part of the project. Head over to <https://cla.developers.google.com/> to see
12+
your current agreements on file or to sign a new one.
13+
14+
You generally only need to submit a CLA once, so if you've already submitted one
15+
(even if it was for a different project), you probably don't need to do it
16+
again.
17+
18+
## Code reviews
19+
20+
All submissions, including submissions by project members, require review. We
21+
use GitHub pull requests for this purpose. Consult
22+
[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
23+
information on using pull requests.
24+
25+
## What to expect from maintainers
26+
27+
Expect maintainers to respond to new issues or pull requests within a week.
28+
For outstanding and ongoing issues and particularly for long-running
29+
pull requests, expect the maintainers to review within a week of a
30+
contributor asking for a new review. There is no commitment to resolution --
31+
merging or closing a pull request, or fixing or closing an issue -- because some
32+
issues will require more discussion than others.

vendor/cel.dev/expr/GOVERNANCE.md

+43
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
# Project Governance
2+
3+
This document defines the governance process for the CEL language. CEL is
4+
Google-developed, but openly governed. Major contributors to the CEL
5+
specification and its corresponding implementations constitute the CEL
6+
Language Council. New members may be added by a unanimous vote of the
7+
Council.
8+
9+
The MAINTAINERS.md file lists the members of the CEL Language Council, and
10+
unofficially indicates the "areas of expertise" of each member with respect
11+
to the publicly available CEL repos.
12+
13+
## Code Changes
14+
15+
Code changes must follow the standard pull request (PR) model documented in the
16+
CONTRIBUTING.md for each CEL repo. All fixes and features must be reviewed by a
17+
maintainer. The maintainer reserves the right to request that any feature
18+
request (FR) or PR be reviewed by the language council.
19+
20+
## Syntax and Semantic Changes
21+
22+
Syntactic and semantic changes must be reviewed by the CEL Language Council.
23+
Maintainers may also request language council review at their discretion.
24+
25+
The review process is as follows:
26+
27+
- Create a Feature Request in the CEL-Spec repo. The feature description will
28+
serve as an abstract for the detailed design document.
29+
- Co-develop a design document with the Language Council.
30+
- Once the proposer gives the design document approval, the document will be
31+
linked to the FR in the CEL-Spec repo and opened for comments to members of
32+
33+
- The Language Council will review the design doc at the next council meeting
34+
(once every three weeks) and the council decision included in the document.
35+
36+
If the proposal is approved, the spec will be updated by a maintainer (if
37+
applicable) and a rationale will be included in the CEL-Spec wiki to ensure
38+
future developers may follow CEL's growth and direction over time.
39+
40+
Approved proposals may be implemented by the proposer or by the maintainers as
41+
the parties see fit. At the discretion of the maintainer, changes from the
42+
approved design are permitted during implementation if they improve the user
43+
experience and clarity of the feature.

vendor/cel.dev/expr/MAINTAINERS.md

+13
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
# CEL Language Council
2+
3+
| Name | Company | Area of Expertise |
4+
|-----------------|--------------|-------------------|
5+
| Alfred Fuller | Facebook | cel-cpp, cel-spec |
6+
| Jim Larson | Google | cel-go, cel-spec |
7+
| Matthais Blume | Google | cel-spec |
8+
| Tristan Swadell | Google | cel-go, cel-spec |
9+
10+
## Emeritus
11+
12+
* Sanjay Ghemawat (Google)
13+
* Wolfgang Grieskamp (Facebook)

vendor/cel.dev/expr/MODULE.bazel

+70
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
module(
2+
name = "cel-spec",
3+
)
4+
5+
bazel_dep(
6+
name = "bazel_skylib",
7+
version = "1.7.1",
8+
)
9+
bazel_dep(
10+
name = "gazelle",
11+
version = "0.36.0",
12+
repo_name = "bazel_gazelle",
13+
)
14+
bazel_dep(
15+
name = "googleapis",
16+
version = "0.0.0-20240819-fe8ba054a",
17+
repo_name = "com_google_googleapis",
18+
)
19+
bazel_dep(
20+
name = "protobuf",
21+
version = "26.0",
22+
repo_name = "com_google_protobuf",
23+
)
24+
bazel_dep(
25+
name = "rules_cc",
26+
version = "0.0.9",
27+
)
28+
bazel_dep(
29+
name = "rules_go",
30+
version = "0.49.0",
31+
repo_name = "io_bazel_rules_go",
32+
)
33+
bazel_dep(
34+
name = "rules_java",
35+
version = "7.6.5",
36+
)
37+
bazel_dep(
38+
name = "rules_proto",
39+
version = "6.0.0",
40+
)
41+
bazel_dep(
42+
name = "rules_python",
43+
version = "0.35.0",
44+
)
45+
46+
### PYTHON ###
47+
python = use_extension("@rules_python//python/extensions:python.bzl", "python")
48+
python.toolchain(
49+
ignore_root_user_error = True,
50+
python_version = "3.11",
51+
)
52+
53+
switched_rules = use_extension("@com_google_googleapis//:extensions.bzl", "switched_rules")
54+
switched_rules.use_languages(
55+
cc = True,
56+
go = True,
57+
java = True,
58+
)
59+
use_repo(switched_rules, "com_google_googleapis_imports")
60+
61+
go_sdk = use_extension("@io_bazel_rules_go//go:extensions.bzl", "go_sdk")
62+
go_sdk.download(version = "1.21.1")
63+
64+
go_deps = use_extension("@bazel_gazelle//:extensions.bzl", "go_deps")
65+
go_deps.from_file(go_mod = "//:go.mod")
66+
use_repo(
67+
go_deps,
68+
"org_golang_google_genproto_googleapis_rpc",
69+
"org_golang_google_protobuf",
70+
)

vendor/cel.dev/expr/README.md

+73
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
# Common Expression Language
2+
3+
The Common Expression Language (CEL) implements common semantics for expression
4+
evaluation, enabling different applications to more easily interoperate.
5+
6+
Key Applications
7+
8+
* Security policy: organizations have complex infrastructure and need common
9+
tooling to reason about the system as a whole
10+
* Protocols: expressions are a useful data type and require interoperability
11+
across programming languages and platforms.
12+
13+
14+
Guiding philosophy:
15+
16+
1. Keep it small & fast.
17+
* CEL evaluates in linear time, is mutation free, and not Turing-complete.
18+
This limitation is a feature of the language design, which allows the
19+
implementation to evaluate orders of magnitude faster than equivalently
20+
sandboxed JavaScript.
21+
2. Make it extensible.
22+
* CEL is designed to be embedded in applications, and allows for
23+
extensibility via its context which allows for functions and data to be
24+
provided by the software that embeds it.
25+
3. Developer-friendly.
26+
* The language is approachable to developers. The initial spec was based
27+
on the experience of developing Firebase Rules and usability testing
28+
many prior iterations.
29+
* The library itself and accompanying toolings should be easy to adopt by
30+
teams that seek to integrate CEL into their platforms.
31+
32+
The required components of a system that supports CEL are:
33+
34+
* The textual representation of an expression as written by a developer. It is
35+
of similar syntax to expressions in C/C++/Java/JavaScript
36+
* A representation of the program's abstract syntax tree (AST).
37+
* A compiler library that converts the textual representation to the binary
38+
representation. This can be done ahead of time (in the control plane) or
39+
just before evaluation (in the data plane).
40+
* A context containing one or more typed variables, often protobuf messages.
41+
Most use-cases will use `attribute_context.proto`
42+
* An evaluator library that takes the binary format in the context and
43+
produces a result, usually a Boolean.
44+
45+
For use cases which require persistence or cross-process communcation, it is
46+
highly recommended to serialize the type-checked expression as a protocol
47+
buffer. The CEL team will maintains canonical protocol buffers for ASTs and
48+
will keep these versions identical and wire-compatible in perpetuity:
49+
50+
* [CEL canonical](https://github.com/google/cel-spec/tree/master/proto/cel/expr)
51+
* [CEL v1alpha1](https://github.com/googleapis/googleapis/tree/master/google/api/expr/v1alpha1)
52+
53+
54+
Example of boolean conditions and object construction:
55+
56+
``` c
57+
// Condition
58+
account.balance >= transaction.withdrawal
59+
|| (account.overdraftProtection
60+
&& account.overdraftLimit >= transaction.withdrawal - account.balance)
61+
62+
// Object construction
63+
common.GeoPoint{ latitude: 10.0, longitude: -5.5 }
64+
```
65+
66+
For more detail, see:
67+
68+
* [Introduction](doc/intro.md)
69+
* [Language Definition](doc/langdef.md)
70+
71+
Released under the [Apache License](LICENSE).
72+
73+
Disclaimer: This is not an official Google product.

0 commit comments

Comments
 (0)