-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to using the new record_ecosystem_versions
endpoint.
#7517
Switch to using the new record_ecosystem_versions
endpoint.
#7517
Conversation
record_ecosystem_versions
endpoint.
96be1bb
to
bed59e8
Compare
c2c28d2
to
1716d2c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense to me, 👍🏻
ad0b2a3
to
1c173d8
Compare
@@ -102,7 +102,7 @@ def clone_repo_contents | |||
raise Dependabot::RepoNotFound, source | |||
end | |||
|
|||
def package_manager_version | |||
def ecosystem_versions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs a code comment explaining the expected shape of the data, or possibly a doc somewhere for devs, but we're still noodling internally on what we want this to look like, so punting on those docs until later.
Right now just want to get it swapped over to this new endpoint so can start prototyping actual code to see how my design ideas hold up to reality--ie, do we want to record more/different info then I expect.
1c173d8
to
ee51f3c
Compare
These test failures indicate may need to port the callers of this as part of this PR as well... or bury the package manager calls in private methods since the rspec './spec/dependabot/bundler/file_fetcher_spec.rb[1:1:1:5]' # Dependabot::Bundler::FileFetcher behaves like a dependency file fetcher the class doesn't define any additional public instance methods |
ee51f3c
to
824ea46
Compare
824ea46
to
e508a7e
Compare
This flips the `updater` to calling the new `record_ecosystem_versions` endpoint. Additionally, this flips the per-ecosystem implementations of `package_manager_version` to this new `ecosystem_versions` hash. Note that we expect the shape of the data to be slightly different in the long term for these metrics... ie, we plan to record a `min`/`max`/`raw` or something along those lines for the range of versions supported by the manifest. However, changing that will be done in separate PR's for easier review/discussion/audit of those individual ecosystems. Co-authored-by: Barry Gordon <896971+brrygrdn@users.noreply.github.com>
e508a7e
to
0c2aeae
Compare
This endpoint was renamed in dependabot/dependabot-core#7517 and the accompanying internal API change. So the mock here needs updating. Also updated the struct.
This endpoint was renamed in dependabot/dependabot-core#7517 and the accompanying internal API change. So the mock here needs updating. Also updated the struct.
) This endpoint was renamed in dependabot/dependabot-core#7517 and the accompanying internal API change. So the mock here needs updating. Also updated the struct.
As of dependabot/dependabot-core#7517 we're now using a `record_ecosystem_versions` endpoint instead of `record_package_manager_versions`. So this updates the test expectations accordingly.
I confused myself in the previous two PR's... the `Ecosystem` field is actually removed, and the `PackageManager` field is replaced by the `EcosystemVersions` field. For background context: * #145 * #146 * dependabot/dependabot-core#7492 * dependabot/dependabot-core#7517 Caught this discrepancy over here: * https://github.com/dependabot/smoke-tests/pull/98/files#r1260099204
I confused myself in the previous two PR's... the `Ecosystem` field is actually removed, and the top-level `PackageManager` field is replaced by the `EcosystemVersions` field. As explained in #146, there may be an inner `PackageManager` field, which is optional. But no need to map it out in the struct, at least not yet. For background context: * #145 * #146 * dependabot/dependabot-core#7492 * dependabot/dependabot-core#7517 Caught this discrepancy over here: * https://github.com/dependabot/smoke-tests/pull/98/files#r1260099204
I confused myself in the previous two PR's... the `Ecosystem` field is actually removed, and the top-level `PackageManager` field is replaced by the `EcosystemVersions` field. As explained in #146, there may be an inner `PackageManager` field, which is optional. But no need to map it out in the struct, at least not yet. For background context: * #145 * #146 * dependabot/dependabot-core#7492 * dependabot/dependabot-core#7517 Caught this discrepancy over here: * https://github.com/dependabot/smoke-tests/pull/98/files#r1260099204
I confused myself in the previous two PR's... the `Ecosystem` field is actually removed, and the top-level `PackageManager` field is replaced by the `EcosystemVersions` field. As explained in #146, there may be an inner `PackageManager` field, which is optional. But no need to map it out in the struct, at least not yet. For background context: * #145 * #146 * dependabot/dependabot-core#7492 * dependabot/dependabot-core#7517 Caught this discrepancy over here: * https://github.com/dependabot/smoke-tests/pull/98/files#r1260099204
As of dependabot/dependabot-core#7517 we're now using a `record_ecosystem_versions` endpoint instead of `record_package_manager_versions`. So this updates the test expectations accordingly.
As of dependabot/dependabot-core#7517 we're now using a `record_ecosystem_versions` endpoint instead of `record_package_manager_versions`. So this updates the test expectations accordingly.
This flips the `updater` to calling the new `record_ecosystem_versions` endpoint. Additionally, this flips the per-ecosystem implementations of `package_manager_version` to this new `ecosystem_versions` hash. Note that we expect the shape of the data to be slightly different in the long term for these metrics... ie, we plan to record a `min`/`max`/`raw` or something along those lines for the range of versions supported by the manifest. However, changing that will be done in separate PR's for easier review/discussion/audit of those individual ecosystems. Co-authored-by: Barry Gordon <896971+brrygrdn@users.noreply.github.com>
This flips the
updater
to calling the newrecord_ecosystem_versions
endpoint.
Additionally, this flips the per-ecosystem implementations of
package_manager_version
to this newecosystem_versions
hash.Note that we expect the shape of the data to be slightly different in
the long term for these metrics... ie, we plan to record a
min
/max
/raw
or something along those lines for the range ofversions supported by the manifest.
However, changing that will be done in separate PR's for easier
review/discussion/audit of those individual ecosystems.
Related:
ecosystem
param #7492