Document sourceUrl and releaseTimestamp support in datasources

[rarkins]

Describe the proposed change(s).

Extend

renovate/lib/modules/datasource/types.ts

Lines 111 to 114 in 5de7eee

	/**
	* Whether custom registryUrls are allowed.
	*/
	customRegistrySupport: boolean;

To be like:

  /**
   * Whether custom registryUrls are allowed.
   */
  customRegistrySupport: boolean;

  /**
   * Whether release timestamps can be returned.
   */
   releaseTimestampSupport: boolean;
   releaseTimeStampNote?: string;

  /**
   * Whether sourceURLs can be returned.
   */
   sourceUrlSupport: 'package' | 'release' | 'none';
   sourceUrlNote?: string;

releaseTimestampSupport should be true if the datasources looks for release.releaseTimestamp

sourceUrlSupport should be release if the datasource supports returning them per-release (e.g. npm), package if they can be returned but only per-package (e.g. cdnjs), or none if no sourceUrl logic exists.

The optional note fields should ideally be filled into clarify how the field is determined. e.g in both npm and cdnjs, it's from the repository value in the results. Can we possibly use types to make these note fields mandatory if their sibling field is set?

[rarkins]

In addition to the work above, please create any necessary GitHub issues to add releaseTimestamp or sourceUrl support for any particular datasources which are missing them but for which we think it should be possible.

[HonkingGoose]

The optional note fields should ideally be filled into clarify how the field is determined. e.g in both npm and cdnjs, it's from the repository value in the results. Can we possibly use types to make these note fields mandatory if their sibling field is set?

This sounds like the description field in the Renovate presets. 🙂

I don't know if you can make the note field mandatory with TypeScript. You can probably write a test to check if the note is filled in when the sibling field is set.

[RahulGautamSingh]

In some cases, for eg. bitbucket-tags we determine the sourceUrl by combining registryUrl and packageName. Both of these values are already available to us, and aren't extracted from the response.

Which sourceUrlSupport value should be used in this case?

[rarkins]

In that case, package

[RahulGautamSingh]

sourceUrlSupport: 'package' | 'release' | 'none';

sourceUrlSupport: 'package' | 'release' | 'none' | 'true' ??

[rarkins]

Corrected to "package". i.e the sourceUrl is returned per package and we don't the concept of sourceUrl per-release

[RahulGautamSingh]

What should be done when getDigest supportes releaseTimestamp but getReleases does not?
For eg.
conan datasource, has the time field in its results for the getDigest api call. But not in the results for the getReleases api call.
For the sourceUrl its the opposite ie. getReleases returns it whereas getDigest does not.

[rarkins]

I'm not sure we use the timestamp for digests. I'd consider that support false if it's not per-release