Files
renovate/lib/modules/datasource
Jamie Tanna e942788539 fix(datasource/pypi): use the earliest upload_time of a version (#45313)
* test(datasource/pypi): cover which `upload_time` a version reports

As part of future changes to how we calculate the `releaseTimestamp`, it
was clear we don't have as much coverage of this logic.

To make this more explicit, we can add new test coverage.

Additionally, we can introduce a new example from a package to guide
this.

Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>

* fix(datasource/pypi): use the earliest `upload_time` of a version

When calculating the `releaseTimestamp` for the PyPI datasource, we've
been looking at the first entry in the response, which isn't always
the first time this package existed.

In the case that a Wheel is uploaded after the package first was
released - for instance, to support a new version of Python, at an
existing pinned version of the package - this would lead to a
potentially incorrect calculation for the `releaseTimestamp`.

This can lead to Renovate seeing a package as newer than it is, which
can mean that i.e. `minimumReleaseAge` can show as pending for a package
that shouldn't be.

As part of upstream changes[0], this should be less frequent in the
ecosystem, but existing packages still exist with this behaviour.

To fix this, we can make sure that we filter a given Release's
to find the earliest `upload_time`.

Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>

[0]: https://blog.pypi.org/posts/2026-07-22-releases-now-reject-new-files-after-14-days/

---------

Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
2026-08-17 11:01:26 +00:00
..
2026-08-11 10:29:08 +00:00

Datasources

Datasources are used in Renovate primarily to fetch released versions of packages.

Follow the class-based programming style

New datasources must follow the class-based programming style. Use the java-version datasource as a reference.

Add the datasource to the API in api.ts so that the new datasource is usable. If you find Unused HTTP mocks errors in the Vitest tests and your mocked URLs are correct, make sure the datasource is correctly registered.

getReleases

The minimum exported interface for a datasource is a function called getReleases that takes a lookup config as input.

The config has:

  • packageName: the package's full name including scope if present (e.g. @foo/bar)
  • registryUrls: an array of registry URLs to try

getReleases should return an object having:

  • releases: an array of strings of matched versions. This is the only mandatory field
  • deprecationMessage: a string description of the package's deprecation notice, if applicable
  • sourceUrl: a HTTP URL pointing to the source code (for example on GitHub)
  • homepage: a HTTP URL for the package's homepage. Ideally should be empty if the homepage and sourceUrl are the same
  • changelogUrl: a URL pointing to the package's changelog (could be a Markdown file, for example). If not present then Renovate will search the sourceUrl for a changelog file
  • tags: an object mapping tag → version, for example tags: { latest: '3.0.0' }. This is only used by the followTags function

getDigest

Datasources that support digests (like Docker digests and Git commit hashes) can export a getDigest function.

The getDigest function has two inputs:

  • config: the Renovate config for the package being updated, has the same fields as getReleases
  • newValue: the version or value to retrieve the digest for

The getDigest function returns a string output representing the digest value. If no digest is found, the getDigest function should return null.