dustinmoris / ci-buildstats Goto Github PK

Hi,
I am trying to insert badge into README with following syntax
.

And it seems like buildstats cannot found my package.

You may need a bit more horse power on your build / badge server. We're pretty consistently seeing timeouts across the board. Would you recommend we run our own server?

I tried a badge for my package:

At the time of writing, the current version is 2.0.1 (as of an hour ago), with 2.0.0 a month old.
However, the badge reports v1.1.3.

This may be because versions 2.0.0 and up use SemVer 2.0.0 and have build metadata included in the full name. The full version id for v2.0.0 is 2.0.0+20200322.182103.397 and that of v2.0.1 is 2.0.1+20200417.165623.692.

I've just noticed that the bars on the graph on my repo are being shown "backwards".

I would expect the graph to be chronological with the X axis being time increasing towards the right, but the latest build is the first bar instead of the last.

https://ci-buildstats.azurewebsites.net/appveyor/chart/martincostello/sqllocaldb?branch=master&includeBuildsFromPullRequest=false

Is this by design, as it seems counter-intuitive to me?

I'm trying to render an AppVeyor CI graph for a new repo, but I'm getting an HTTP 500 error.

Would be great to be able to specify a custom label.
Instead of just showing nuget we could show the package name for instance.

When filtering by a branch you get the results of all workflows, however we only really want to see the one workflow we have for CI. Our other workflows like packaging and linting take much less time, run at a different cadence, and aren't as important to us from a graph perspective. With those included, what happens is we have tall spikes mixed with short spikes, and is included in values like "average time".

For some NuGet packages badge show wrong stats

Run one Redis cache in Kubernetes used by all other pods.

When I reference a MyGet badge like:
https://buildstats.info/myget/wiremock-net/WireMock.Net
I get response:
Package not found

However this worked before and the package is present:
https://www.myget.org/feed/wiremock-net/package/nuget/WireMock.Net

?

Markdown looks like:

Currently I cant find a way to recolor certain parts in the badges.

Like :
https://buildstats.info/nuget/LinqKit.Microsoft.EntityFrameworkCore?packageVersion=1.1.16 ?

this gives https://buildstats.info/nuget/NServiceBus.PostgreSQL

BuildStats.info

Internal Error

The server encountered an internal error while processing your request.

but all my other ones work. Is there any more info/help i can give?

BTW keep up the awesome work

I noticed that since a couple of weeks the nuget stats are no longer updated. Take NUnit, for instance: now it has 66.11m downloads, insted the widget continues to shows 65.33m.

I started using the project very early on so had a lot of projects using the Azure URL instead of the custom buildstats.info URL and they all recently stopped working as it looks like the hosting provider has changed.

I've fixed my URLs now, but maybe it would be worth setting up a free Azure instance that 302s to the custom domain?

We're using an Enterprise MyGet tenent for publishing our daily builds.

Within that tenant, we've got feeds, such as our daily build feed.

I would love to be able to use your tooling to have links to these packages. The code in PackageServices.fs looks like it needs a MyGet Enterprise module with a slightly different API - as it would need to take slightly different parameters as the DNS name differs between tenants.

I would be happy to personally donate $20 or $50 to have this working. I don't think I have time to submit a PR... (my life is busy in bot-land!)

New repositories/accounts created with Travis CI may now be created at travis-ci.com instead of travis-ci.org as part of Travis' infrastructure migration.

As the API URL is hard-coded at present, it is not possible to generate charts for builds in travis-ci.com.

Two possible approaches to support this could be either:

1. Adding a query-string parameter to specify that the .com version should be used (?v=2 ?).
2. Adding a new provider (travisci2 ?).

This seems to work:
https://buildstats.info/github/chart/davidkassa/dvc-rofr-stats?includeBuildsFromPullRequest=false

This does not:
https://buildstats.info/github/chart/davidkassa/dvc-rofr-stats?includeBuildsFromPullRequest=false&branch=develop

Both worked with Travis CI. I'm not sure if I need to update my branch due to how Actions work, or if it's not supported.

Azure Pipelines has the new concept of Stages when defining a yaml only build and deployment. It also has a matrix, so you can run the build on Linux, Mac and Windows. Here is an example repo and build:

https://github.com/RehanSaeed/Schema.NET
https://dev.azure.com/schema-net/Schema.NET/_build?definitionId=1&_a=summary

Here is the URL I'm trying to use with buildstats.info:

https://buildstats.info/azurepipelines/chart/RehanSaeed/schema-net/1

I think it needs a way to determine the stage and matrix name like Azure DevOps does (although they combine the two concepts together and call it 'Scope'):

These are the options in the Scope dropdown:

It allows me to create badges for the overall pipeline or the individual matrices (Linux, Mac, Windows) for a particular stage (Build or Deploy in my case).

Also note that even Azure Pipelines badge is not yet working. It shows unknown but I've raised a bug with them about that.

I've been experimenting with the gadget on a number of existing builds with AppVeyor and Travis CI, and it appears that builds from all branches are considered, including builds related to Pull Requests.

Would it be possible to add a query string parameter (or a route parameter) that allows the branch to be specified, for example:

https://ci-buildstats.azurewebsites.net/{buildSystem}/chart/{account}/{project}/{branch}

Similar badge providers have the same functionality.

I've set up a new project in Travis CI yesterday, but the chart consistently states there no builds available when there are:

• Project
• Travis CI

I setup the project as private in GitHub initially while I got things set up before making it public, and I'm wondering whether something has cached something from when it was private that means that it's not getting the now-public status?

I'd suggest using your own domain rather than the azurewebsites.net subdomain (ci-buildstats.azurewebsites.net), even if the domain just redirects to the azurewebsites one. Using an azurewebsites subdomain means all the image URLs will break if you ever move to a different host.

Hi Dustin - You don't have any samples of using this to capture code coverage values over time using Azure DevOps, by chance, do you?

It is currently possible to set dwidth to 0, but that currently causes the badge to be rendered as two separate blocks instead of a single image: (it looks like the "nuget" portion of the badge also takes cues about its width from dwidth).

Could that rendering be fixed so that it produces a "complete" looking badge?
Alternatively, would it be possible to add a parameter to indicate that only the latest package version is needed (i.e. leave off the download count)?

The min build times indicate 0 seconds builds times probably due to the canceled builds.
Exemple:

(Screenshot for archive)

Well, they haven't released a decent API yet... So if they do, I would like to help.

The documentation suggests that prerelease versions for the NuGet badge are opt-in, but the service does not appear to be behaving in this way. Is this a regression from the rewrite into F#?

Expected behaviour

URL	Image
https://buildstats.info/nuget/JustEat.StatsD
https://buildstats.info/nuget/JustEat.StatsD?includePreReleases=false
https://buildstats.info/nuget/JustEat.StatsD?includePreReleases=true

Actual behaviour

URL	Image
https://buildstats.info/nuget/JustEat.StatsD
https://buildstats.info/nuget/JustEat.StatsD?includePreReleases=false
https://buildstats.info/nuget/JustEat.StatsD?includePreReleases=true

Note: The expected behaviour badges use a different URL that that listed in the table next to them so that the image is rendered correctly for illustrating the issue.

A wrong name in the URL gives a 500 / Yellow page of death.

https://ci-buildstats.azurewebsites.net/appveyor/chart/a/b

Would it be possible to show them as grey instead? I noticed some of the other parsers have a cancelled status, but TravisCI does not (See here). I tried changing it myself, but I don't see a cancelled status in the API callback, which is perhaps the real issue. However, the ruby gem somehow returns a cancelled status and I can't understand yet where that's coming from. I know Travis has an "old" API and a "new" API, so perhaps that's part of the issue.

It seems that my build history stopped working when I changed my default branch from master to main. Specifying no branch goes to master, though I can't tell if it's a history from travis-ci.com or .org. When I specify main, no builds are found. I assume this is because it's listed as the default branch.

https://buildstats.info/travisci/chart/davidkassa/dvc-rofr-stats?includeBuildsFromPullRequest=false&branch=main
https://buildstats.info/travisci/chart/davidkassa/dvc-rofr-stats?includeBuildsFromPullRequest=false

I've started using the graph on tlslite-ng but the graph for Travis-CI build times is quite confusing:

From what I can tell, the time used for the graph is the wall clock time it took Travis to execute the job.
Problem is that I have multiple repositories and if there are builds in parallel, not all 5 runners are available for this particular project, causing the real time execution to take longer.

Causing builds like #766 to take 31m28s while the total time was 1 h 24 min 27 sec and average time for individual jobs was about 3m.

If we compare it to #767 which supposedly took 7m36s, while the total time was 1 h 27 min 7 sec and average time of the job didn't change much – being around 3m.

Or the #772 which took 19m19s, but 1 h 26 min 52 sec total, with average around 3m still.

From development point of view, it's good to know if the build times are not increasing too fast (as that could be a performance regression), and for that, average build time would be most useful (as it wouldn't be affected much by addition or removal of environments), but it looks like even the switch to "total time" would be better as that is far less variable than the wall clock time of the jobs.

Would it possible to add a switch that would use either average job time or total build time for the graph?

Please add support for GitHub packages! For projects that utilize this GitHub feature will enable for Used by to be discover by the platform much more easily. This is also an alternative to MyGet nuget feed that normally use for publish dev CI build packages before publishing release to nuget.

https://github.com/wangkanai/Detection/packages

Looks like something has gone down, and the charts are not currently working:

I like the idea of this cool badge, but we are only interested in the status of one branch (the master branch).

For example:

Hi,

I am having an issue grabbing the image for my specific package: https://www.nuget.org/packages/Faker.Data/1.0.5

When I insert https://buildstats.info/nuget/faker.data, I get a 404 error.
When I insert https://buildstats.info/nuget/faker I get my image.

The problem is, there are a lot of faker packages (including a "Faker" package) on NuGet, so I don't know why it picked mine.

As the download counts of packages get wider, it causes overall width to change. This makes tables of these look jagged.

Consider a "Fixed width" or a "Padded Width" or "Normalize To" as an option.

An easy answer may simply be parameters for width for 2 two variable fields:

downloadCountWidth=500px
versionWidth=300px

The downloadCountWidth would let me deal with packages that have low (or high) counts.
The versionWidth would let me deal with the version labels like "-preview", "-daily", and so on.

For example, something like:
[![BotBuilder Badge](https://buildstats.info/myget/botbuilder/botbuilder-v4-dotnet-daily/Microsoft.Bot.Builder.AI.LUIS?includePreReleases=true&downloadCountWidth=500px&versionWidth=300px)](https://botbuilder.myget.org/feed/botbuilder-v4-dotnet-daily/package/nuget/Microsoft.Bot.Builder.AI.LUIS)