Fix deliveryservice_stats API to use already-vendored influxdb client, fix RPM builds to discover all vendor dirs#3990
Conversation
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
ocket8888
left a comment
There was a problem hiding this comment.
Builds, tests pass, weasel likes it.
|
retest this please |
|
Refer to this link for build results (access rights to CI server needed): |
|
Hold up, marked this WIP while I investigate build issues. It seems like the RPM build process isn't discovering the top-level |
|
Refer to this link for build results (access rights to CI server needed): |
Fix the Go builds so that they don't download dependencies that we have vendored in our repo. Only the golang.org/x/* packages should be downloaded each time, otherwise the vendored deps should always be used for the build.
6f02b6f to
69a90f0
Compare
|
Refer to this link for build results (access rights to CI server needed): |
ocket8888
left a comment
There was a problem hiding this comment.
Works, tests pass, weasel still likes it
|
retest this please |
|
Refer to this link for build results (access rights to CI server needed): |
|
retest this please |
|
Refer to this link for build results (access rights to CI server needed): |
|
ok, CI is busted. |
What does this PR (Pull Request) do?
Move the vendored influxdb library to the top-level vendor dir for TO and TS to share. Fix the deliveryservice_stats API to use the already-vendored library. Fix the rpm builds for TO, TM, and TS to properly discover all vendor dirs the repo and make the RPM builds fail if unvendored dependencies are added (except for the
golang.org/x/*packages).Which Traffic Control components are affected by this PR?
What is the best way to verify this PR?
GET /api/1.1/deliveryservice_stats, make sure the endpoint still worksThe following criteria are ALL met by this PR