Skip to content

ci: make bazel.debug build and test from a consuming project.#742

Merged
mattklein123 merged 2 commits intoenvoyproxy:masterfrom
htuch:envoy-consumer
Apr 12, 2017
Merged

ci: make bazel.debug build and test from a consuming project.#742
mattklein123 merged 2 commits intoenvoyproxy:masterfrom
htuch:envoy-consumer

Conversation

@htuch
Copy link
Copy Markdown
Member

@htuch htuch commented Apr 12, 2017

This allows us to catch in CI breakages such as those fixed in #732. Also, it allows us to validate
our example and story for other projects that consume Envoy for custom linking of filters keeps
working.

This adds the requirement of bind mounting in docker run with -v :/build for bazel.debug
and bazel.coverage builds.

This allows us to catch in CI breakages such as those fixed in envoyproxy#732. Also, it allows us to validate
our example and story for other projects that consume Envoy for custom linking of filters keeps
working.

This adds the requirement of bind mounting in docker run with -v <some path>:/build for bazel.debug
and bazel.coverage builds.
# This is the hash on https://github.com/htuch/envoy-consumer.git we pin to.
(cd "${ENVOY_CONSUMER_SRCDIR}" && git checkout 94e11fa753a1e787c82cccaec642eda5e5b61ed8)

# Also setup some space for building Envoy standadlone.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo standadlone

${BAZEL} build ${BAZEL_BUILD_OPTIONS} //source/exe:envoy-static
${BAZEL} test ${BAZEL_BUILD_OPTIONS} --test_output=all \
--cache_test_results=no //test/...
cd "${ENVOY_CONSUMER_SRCDIR}"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there value in continuing to build/test just the main project? I can't think of anything off the top of my head but I'm wondering if we are going to miss some type of failure that only shows up when attempting to built the primary project standalone?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can cover the build/test of just the main project in the coverage run. When we formalize the build/test matrix we can make this explicit. I think it's useful to make sure that we're checking the main project build/test is sane, but it's not worth burning CI on it today at least (when we free up jobs when removing cmake we could consider this).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup makes sense. As long as we do at least one build that doesn't use consumer I think that's fine.

export BUILD_DIR=/build
# Make sure that "docker run" has a -v bind mount for /build, since cmake
# users will only have a bind mount for /source.
if [[ ! -a "${BUILD_DIR}" ]]
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does -d work for the bind mounts? IIRC -a is deprecated so maybe use -e ?

export BAZEL_BUILD_OPTIONS="--strategy=CppCompile=standalone --strategy=CppLink=standalone \
--strategy=TestRunner=standalone --strategy=ProtoCompile=standalone \
--strategy=Genrule=standalone --verbose_failures --package_path %workspace%:.."
export BAZEL_BUILD_OPTIONS="--strategy=Genrule=standalone --spawn_strategy=standalone \
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the change in options?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simplified, this is the easiest way to disable all sandboxing on the command-line.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(and package_path had to change since we've changed the relative build location)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I build on my own machine inside the consuming project, I don't seem to need to set --package_path. Out of curiosity why is this necessary here?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe because of the submodule situation?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're building for non-consuming now in /build/envoy, this is where we invoke Bazel. So, it needs to know that it can still find the Envoy source in /source https://bazel.build/versions/master/docs/bazel-user-manual.html#flag--package_path

@mattklein123 mattklein123 merged commit 70030ed into envoyproxy:master Apr 12, 2017
mathetake added a commit that referenced this pull request Mar 3, 2026
**Description**

Previously, there's a bit of race condition where the gateway pod
mutation hook can be called before the secret config is created by the
Gateway controller. That resulted in blocking the Envoy pods from
starting up. This resolves the issue by doing lazy mutation until the
secret is created.


**Related Issues/PRs (if applicable)**

Closes #742

---------

Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants