perltoolsteam / dashboard Goto Github PK

I use Travis, Coveralls.io, and Codecov.io, but I don't use them for all projects.

Testing for the presence of a .travis.yml file in the repo is a simple way to check if the project uses Travis, but it might be prohibitively expensive to do that for hundreds of repos every cron run.

The others are trickier to check.

Right now the table is forced to be pretty narrow, so the dates for many distros are getting wrapped as:

YYYY-
MM-DD

I've just fixed the mechanism that lets an author define a default order for the table on their page (see 14a4215). This had never worked (because it needed a column number and we were using names) and it had broken even more when I added another column without fixing the numbers in the JS config.

I'll be adding columns and maybe moving columns about in the future, so the current approach isn't scalable. We need to go back to allowing authors to specify their default sort column by name - and then have a hash to convert that to a number.

Maybe also think about storing the current sort order in a cookie.

so during development one can restrict the processing to one author thereby reducing the time needed to rerun the process

Strictly, this tracks distributions, not modules. Should change the output to mention, for example, App-Aphra, not App::Aphra.

After updating my JSON file to have multiple builds on Github, only Linux builds show up in my dashboard.

Looks like we need to install gh explicitly now.

https://github.com/PerlToolsTeam/dashboard/actions/runs/6683660981/job/18160086317

Can we have different metadata for the author pages?

How and when do you generate the docs/ directory?
Do you do it manually on your computer and the commit and push?
Wouldn't it be better to create a GitHub Action that will re-generate the docs/ directory on every push and periodically once a day?

For example, not all of my repos have GitHub Actions configured.

I think this may work, but I haven't had time to play with this yet (Stackoverflow:

$('img').error(function() {
    $(this).attr('src', '/no-img.png').addClass('no-img');
});

For modules which use RT as their tracker, a mouse-over the "RT" link shows the message

This module uses CPAN RT as its bugtracker. This service will be closed down on 2021-03-01.

But of course RT did not close down (thankfully). The second sentence should probably now be removed.

When we add an author, we need to add a directory for that author under /docs

I've just added this to https://cpan-digger.perlmaven.com/ and it would be nice to add it here too.

my $cover = $mcpan->cover('Moo-2.23');
if (defined $cover->criteria) {
    $total =  $cover->criteria->{total};
}

The default sort order for releases appears to be alphabetical. In my case this brings up an Acme module that I wrote a long time ago and don't really care about. What I do care about is my more recent uploads, so I'd like to see those first be default ideally. If not, I'd like to be able to have that column be sortable. I feel like it was before, but I can't sort by it on the currently deployed site.

I have several named workflows that I'd like to track.

Since you have a CNAME file and messing with that on my side would screw up pull requests, I need to figure out some way for links to resolve in my fork. My github pages address for this repo is briandfoy.github.io/dashboard/.

Haven't thought about how to do this yet. A simple fix might be to simply make the links to the authors a relative link.

Thanks for adding the Bugs column.
Is it now showing a different bug for RT and anything else?
Maybe there could be some indications where the explicit bugtracker information is RT (and a different one where there is no bugtracker)

Currently, we use the GitHub API (GraphQL) to query the default branch for each repo. And we do this on each rebuild of the data.

The GraphQL API is rate-limited. The documentation says:

The GraphQL API rate limit is 5,000 points per hour.

Note that 5,000 points per hour is not the same as 5,000 calls per hour: the GraphQL API and REST API use different rate limits.

We're currently tracking almost 700 repos and I'm finding that if I collect the data more than a couple of times an hour, I'm running into rate limitations.

The default branch for a repo will change very rarely. Pretty much never in most cases, I expect. So we can probably safely cache the data - requerying it once a day, perhaps - and avoid hitting the limits.

Since that service no longer exists, it would be less confusing it it were removed.

That would save a column in the table.

Maybe even allow the author to configure if they want the default sorting to be abc or date.

Maybe even have start-date, to display only distributions that were released after that date. (or have a clear separation between "old" and "new" releases.

In general I'd primarily only care about my recent distributions as I don't plan to invest energy in old ones, nut until there is a reason to upload a new version of them.

I have several named workflows that I'd like to track.

Some suggestions:

• Dashboard::BadgeMaker ✅
• Dashboard::Author
• Dashboard::Module
• Dashboard::Exception::*

I think the instruction could be greatly simplified and one might even be able to create a sign-up form that will prepare the json file for the commit and pull-request.
One does not need to fork and clone the repository as you can add a file on the web interface of GitHub. (GitHub will create a fork, but I don't need to do it myself)
There could even be an HTML form to fill out with the necessary information that would generate the json file and prepare it to be added via the web interface.

Need a workflow that rebuilds repo_def_branch.json daily.

My page: https://cpandashboard.com/SZABGAB/ has insecure warning because many of my repo-links are old and point to http instead of https. I don't think I want to release a new version of these module just to fix this issue, but I wonder

1. Should the dashboard replace the http://github.com links by https://github.com during processing?
2. Should there be some indication on the page which are the distros with http link if any?

Maybe at the bottom of the page there could be a list of these modules for the author to consider fixing.

https://metacpan.org/author/TOBYINK says @tobyink has 299 distributions, ( https://cpan.rocks/ shows the same number )
https://cpandashboard.com/TOBYINK/ only has 246 entries

https://metacpan.org/author/SZABGAB has 31 according to MetaCPAN, but only 24 on https://cpandashboard.com/SZABGAB/

What is the source of these differences?

Further checking seems to indicate that the distros that don't indicated their repository in META.json are excluded.

IMHO it would be nice to list those as well and indicate they are missing the repos and maybe an explanation how to add the links.

After I removed Cirrus and Appveyor from my JSON file they still show up in my dashboard

I started using codecov.io instead of coveralls.io for a repos during a long period the coveralls.io website had issues with sorting/filtering files to see which had worst coverage. (They've fixed the issue now, but it persisted for months!)

It is still pretty valuable to have. Coveralls.io only checks each line is covered; codecov.io tracks branch conditions, so in foo() ? bar() : baz(), codecov.io will only be happy if both the bar and baz functions get called.

Example of codecov:
https://codecov.io/gh/tobyink/p5-type-tiny

See here

What do you think about a page e.g. /recent that would show the N most recently uploaded distributions regardless of author?

I just ran the dashboard locally and saw a number of processing errors. I see them in the GitHub Actions output as well.
I wonder if it would be a good idea to create a page called "errors" on the web site and show the most recent processing errors there.

Can't we get the list of distributions belonging to a user from the MetaCPAN API?

Is this a good idea? If they don't care, then why are the modules still on CPAN? Maybe we include a list of "legacy modules" at the bottom of each author's page.

We're starting to see some new GitHub repos appear with a default branch of main instead of master. This is a problem as we're currently assuming the branch name master in some of the image links. So this needs some thinking about.

Three options that immediately spring to mind:

• Accept that it will only work if you're interested in the main branch (this might be the quickest fix, but I want to do something cleverer in the medium term)
• Ask authors to list any repos that don't use master as the default branch (but I really want to avoid authors having to list their modules if I can possibly avoid it)
• Some kind of GitHub API magic that works out what the default branch is for any given repo

And then there's a wider question of whether authors want to see results for branches other than the default branch.

I think instead of having it in the README the instructions about Travis-CI (and GitHub Actions etc.) should be in a web page.
That page can then be linked from the Dashboard or from the menu of the site.

Using command line flags
This will make it easier to work on the pages without collecting all the data again and again.

Saving the data for each author in json files in the docs/ folder can also provide an extra service for those (few) who might want to reuse this data.