chore: upgrade all the dependencies to their latest versions (#3454)

* chore: go get -u ./...

* chore: go mod tidy

* chore: go mod vendor

* chore: fix compilation for buildkit >= 0.15.0

* chore: upgrade to Go 1.24

* chore: upgrade the Debian container used in an integration test

Author: plumpy

deploy/Dockerfile

@@ -12,7 +12,7 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-FROM golang:1.22 AS builder
+FROM golang:1.24 AS builder
 WORKDIR /src
 
 # This arg is passed by docker buildx & contains the target CPU architecture (e.g., amd64, arm64, etc.)

go.mod

@@ -1,4 +1,4 @@
-FROM debian:10.2 AS first
+FROM debian:12 AS first
 CMD ["mycmd"]
 FROM first
 ENTRYPOINT ["myentrypoint"] # This should clear out CMD in the config metadata

go.sum

@@ -70,7 +70,7 @@ func ResolveEnvironmentReplacementList(values, envs []string, isFilepath bool) (
 // "a\"b" -> "a"b"
 func ResolveEnvironmentReplacement(value string, envs []string, isFilepath bool) (string, error) {
 	shlex := shell.NewLex(parser.DefaultEscapeToken)
-	fp, _, err := shlex.ProcessWord(value, envs)
+	fp, _, err := shlex.ProcessWord(value, shell.EnvsFromSlice(envs))
 	// Check after replacement if value is a remote URL
 	if !isFilepath || IsSrcRemoteFileURL(fp) {
 		return fp, err

integration/dockerfiles/Dockerfile_test_cmd

@@ -0,0 +1,2 @@
+7.3.2
+# Keep this pinned version in parity with cel-go

pkg/util/command_util.go

@@ -0,0 +1,2 @@
+*.pb.go linguist-generated=true
+*.pb.go -diff -merge

vendor/cel.dev/expr/.bazelversion

@@ -0,0 +1,2 @@
+bazel-*
+MODULE.bazel.lock

vendor/cel.dev/expr/.gitattributes

@@ -0,0 +1,25 @@
+# Contributor Code of Conduct
+## Version 0.1.1 (adapted from 0.3b-angular)
+
+As contributors and maintainers of the Common Expression Language
+(CEL) project, we pledge to respect everyone who contributes by
+posting issues, updating documentation, submitting pull requests,
+providing feedback in comments, and any other activities.
+
+Communication through any of CEL's channels (GitHub, Gitter, IRC,
+mailing lists, Google+, Twitter, etc.) must be constructive and never
+resort to personal attacks, trolling, public or private harassment,
+insults, or other unprofessional conduct.
+
+We promise to extend courtesy and respect to everyone involved in this
+project regardless of gender, gender identity, sexual orientation,
+disability, age, race, ethnicity, religion, or level of experience. We
+expect anyone contributing to the project to do the same.
+
+If any member of the community violates this code of conduct, the
+maintainers of the CEL project may take action, removing issues,
+comments, and PRs or blocking accounts as deemed appropriate.
+
+If you are subject to or witness unacceptable behavior, or have any
+other concerns, please email us at
+[cel-conduct@google.com](mailto:cel-conduct@google.com).

vendor/cel.dev/expr/.gitignore

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