Fix CI for release/v1.18

[RyanTheOptimist]

Backport: examples: Fix flask import (#20038)

Signed-off-by: Ryan Northey ryan@synca.io
Signed-off-by: phlax phlax@users.noreply.github.com

---

Backport: build(deps): bump github/codeql-action from 1.1.2 to 1.1.3 (#20107)

Bumps github/codeql-action from 1.1.2 to 1.1.3.

• Release notes
• Changelog
• Commits

updated-dependencies:

• dependency-name: github/codeql-action
  dependency-type: direct:production
  update-type: version-update:semver-patch

Signed-off-by: dependabot[bot] support@github.com
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: Ryan Hamilton rch@google.com

---

Backport: ci: not using alpine image in examples (#19805)

Signed-off-by: Lizan Zhou lizan@tetrate.io
Signed-off-by: Ryan Hamilton rch@google.com

[ggreenway]

The mac CI failure isn't one I've seen before. Is this a gURL issue?

Undefined symbols for architecture x86_64:
  "std::__1::basic_string<unsigned short, gurl_base::string16_internals::string16_char_traits, std::__1::allocator<unsigned short> >::shrink_to_fit()", referenced from:
      bool gurl_base::(anonymous namespace)::UTFConversion<gurl_base::BasicStringPiece<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::basic_string<unsigned short, gurl_base::string16_internals::string16_char_traits, std::__1::allocator<unsigned short> > >(gurl_base::BasicStringPiece<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > const&, std::__1::basic_string<unsigned short, gurl_base::string16_internals::string16_char_traits, std::__1::allocator<unsigned short> >*) in libstrings.a(utf_string_conversions.o)
      bool gurl_base::(anonymous namespace)::UTFConversion<gurl_base::BasicStringPiece<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > >, std::__1::basic_string<unsigned short, gurl_base::string16_internals::string16_char_traits, std::__1::allocator<unsigned short> > >(gurl_base::BasicStringPiece<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > > const&, std::__1::basic_string<unsigned short, gurl_base::string16_internals::string16_char_traits, std::__1::allocator<unsigned short> >*) in libstrings.a(utf_string_conversions.o)
ld: symbol(s) not found for architecture x86_64```

/wait

[RyanTheOptimist]

Yeah, the mac error is #20245
I thought I'd be able to sort out the verify_examples failures but something is going on there I don't seem to be able to cargo cult my way out of. dynamic-config-cp passes for me locally but not in CI. (I'm not super familiar with verify_examples so I'm probably missing something obvious). Maybe we should land this PR as is, and I can file an issue about the remaining verify_examples failures?

[ggreenway]

That's fine with me; you'll need to get a repo-admin to merge it past the CI failure

[RyanTheOptimist]

@mattklein123 Would you care to force merge this to move the CI ball forward? I filed #20360 to track the underlying failure.

[daixiang0]

Pin commit looks good to me.

[phlax]

@RyanTheOptimist here is a diff which i think will fix the cache example (if the flask pip install is also fixed) didnt work 8/

diff --git a/examples/cache/docker-compose.yaml b/examples/cache/docker-compose.yaml
index 058cf203b3..98619eba73 100644
--- a/examples/cache/docker-compose.yaml
+++ b/examples/cache/docker-compose.yaml
@@ -5,8 +5,6 @@ services:
     build:
       context: .
       dockerfile: Dockerfile-frontenvoy
-    networks:
-      - envoymesh
     ports:
       - "8000:8000"
 
@@ -16,8 +14,6 @@ services:
       dockerfile: Dockerfile-service
     volumes:
       - ./responses.yaml:/etc/responses.yaml
-    networks:
-      - envoymesh
     environment:
       - SERVICE_NAME=1
 
@@ -27,10 +23,5 @@ services:
       dockerfile: Dockerfile-service
     volumes:
       - ./responses.yaml:/etc/responses.yaml
-    networks:
-      - envoymesh
     environment:
       - SERVICE_NAME=2
-
-networks:
-  envoymesh: {}

[phlax]

hmm - actually that didnt fix - i think what i was addressing was more symptom than cause

i think the real issue is as described in #20366

i will raise PRs on each of the active branches to address this issue, and hopefully prevent future breakages

moving forward, i dont see any way around this than manually setting these n the release branches (after the branch has released)