Include date/time for latest scan for tags

[jmh530]

There is a recent dub issue mentioning that the dub registry had not updated that dub itself was a newer version (it has since been updated, so the issue should be closed).
dlang/dub#2721

Nevertheless, it feels like it can take a few days from when a package is tagged to when the new tag shows up in code.dlang.org. If you're just a contributor and not the owner of the repository, you may just have to wait those couple of days for the update to occur on its own. This is especially frustrating if you have another project that depends on the tag being available to build upon (and the recommendation from the code.dlang.org documentation is not to rely on a branch for a dependency).

One thing that might make things a little more transparent is providing some kind of date/time information for the last time the package was scanned for new tags. If the scan happens weekly (or whenever), then at least seeing when the last scan occurred can make it feel more deterministic.

This might be less of an issue if the packages are scanned for new tags more frequently. It might make sense to have some kind of prioritization for packages that are downloaded more frequently.

[WebFreak001]

scans are running continuously, but some packages hang them up for a very long time. Ideally this should not be an issue at all, but for some reason it is hanging up.

If you are a regular contributor to a package, consider asking the DUB owner to grant you access to their package for triggering releases scans.

[jmh530]

@WebFreak001 Thanks. Is there any way to diagnose when the scans hang them up? I have no idea how the dub registry works.

There was a complaint recently about mir-core (here). I also tagged mir-lapack late last week and it hasn't updated yet.

[WebFreak001]

I triggered a manual update of mir-lapack for now, to diagnose you would likely need a lot of packages and it might also be related to github ratelimits.

Maybe @s-ludwig knows more about the issue on the current deployment

[jmh530]

Thanks.

If it is related to github ratelimits, then checking it continuously would be an issue. Slowing down the checks might help with that.

[jmh530]

@WebFreak001 I made a separate issue (#559) just for the issue of packages not getting scanned. I still think it would be useful to provide some statistics for when they had been scanned, but I guess it is downstream of tags not getting scanned.