extensions: Separate generation of extension db from docs in CI#15117
extensions: Separate generation of extension db from docs in CI#15117htuch merged 13 commits intoenvoyproxy:mainfrom
Conversation
57f11dc to
e41dd41
Compare
|
im not 100% how best to separate this, or exactly how it will be required by #15100 - so this PR is currently experimental to figure these things out |
e41dd41 to
12485ed
Compare
2e06e9f to
dbe4373
Compare
|
@htuch would you mind having a look at this one im not sure if its done the best way - using also, i had to change the visibility of the actual |
b4a3d0c to
1f65be9
Compare
Signed-off-by: Ryan Northey <ryan@synca.io>
1f65be9 to
dbffcf8
Compare
|
@phlax generally this is a really nice step. I don't mind hardcoding |
|
Retrying Azure Pipelines: |
|
/retest |
|
Retrying Azure Pipelines: |
|
im pretty sure the coverage test fail is unrelated - retesting doesnt seem to fix |
| "//test/extensions/...", | ||
| "//test/server", | ||
| "//test/server/config_validation", | ||
| "//tools/extensions/...", |
There was a problem hiding this comment.
maybe this should be more specific - not sure if the elipsis is necessary
There was a problem hiding this comment.
afaict this is as narrow as i can get it
Signed-off-by: Ryan Northey <ryan@synca.io>
| if __name__ == '__main__': | ||
| output_path = sys.argv[1] | ||
| try: | ||
| output_path = (os.environ["EXTENSION_DB_PATH"] |
There was a problem hiding this comment.
output_path = os.getenv('EXTENSION_DB_PATH', sys.argv[1])
There was a problem hiding this comment.
this would break if sys.argv[1] is not set (ie even when EXTENSION_DB_PATH was) - hence the if ... else
i think this code could be a bit prettier with different formatting but i think the logic is correct
There was a problem hiding this comment.
i updated to output_path = os.getenv("EXTENSION_DB_PATH") or sys.argv[1] which is more concise and works as expected
| "//test/extensions/...", | ||
| "//test/server", | ||
| "//test/server/config_validation", | ||
| "//tools/extensions/...", |
|
/retest |
|
Retrying Azure Pipelines: |
|
/lgtm deps |
|
@phlax I'll be having a stern word with @htuch on his deps LGTM 😄 The com_github_bazelbuild_buildtools = dict(
project_name = "Bazel build tools",
project_desc = "Developer tools for working with Google's bazel buildtool.",
project_url = "https://github.com/bazelbuild/buildtools",
version = "4.0.1",
sha256 = "0d3ca4ed434958dda241fb129f77bd5ef0ce246250feed2d5a5470c6f29a77fa",
release_date = "2021-03-01",
strip_prefix = "buildtools-{version}",
urls = ["https://github.com/bazelbuild/buildtools/archive/{version}.tar.gz"],
use_category = ["api"],
), |
|
i can add a cleanup if you want |
|
@moderation good point; can we add a check on this kind of hardcoding to the deps validation Python? |
|
A check in deps validation definitely makes sense. Will make an attempt. |
Signed-off-by: Ryan Northey ryan@synca.io
Commit Message: extensions: Separate generation of extension db from docs in CI
Additional Description:
As we will require the extension DB to be generated for docs and schema, it makes sense to separate this task so that those jobs can run in parallel
Im wondering if this job should be moved to a bazel build somewhere - but initially im just gonna get it working by splitting the script/job
UPDATE
rather than separating the ci job, i have moved the db generation into a bazel job - which will allow other tasks that also require this data to make use of it more easily/bazely
this also adds buildozer into the bazel env, so we might want to make use of that elsewhere and potentially remove buildozer from the build-image env
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue] Touch #13229
[Optional Deprecated:]
[Optional API Considerations:]