I’d like to be able to show build/coverage/latest release, etc. in the README.md for the packages in JuliaString, with detailed information in the README.md of each package, and a kind of dashboard in the Strs.jl package that includes many of the other packages.
In particular, I’d like to be able to separate out badges from the appveyor testing, for 32-bit and 64-bit, stable and nightly, latest release and master, and for the Travis testing, for Linux and MacOS, etc., which ends up being 8 badges for each release, plus 1 or 2 coverage badges for master (coveralls and codecov), and a badge that shows the latest release version.
Does anybody know how to do this, or have any suggestions where I might find out if this is even possible?
Thanks in advance!
1 Like
I am not sure if you want to have platform independent statuses (is it really working if it fails on 32-bit or some supported OS? Sometimes I like just supporting 64-bit infrastructure only.). However, you can get the shields and status using the C.I. API, for example:
https://travis-ci.org/Owner/PkgName.jl.svg?branch=v1.0.0
where the branch equals the latest tag or release. I would ditch coveralls and just use codecov. I assume you know how to get the latest released version, but if not you can get the shield and others from https://shields.io/.
2 Likes
That’s the tag/release of the package - how can I split up also based on the version of Julia used?
Haha, you know what they say about “assume”!
All of this trying to get things to look nice with markdown and badges for the READMEs is new to me.
Thanks for the info, and pointer to shields!
For the Julia version one can use the Package Evaluator data:
[](https://pkg.julialang.org/detail/PackageName.html)
The standard way to learn things is to copy it from the Internet (hehe): https://github.com/Nosferican/NCEI.jl as an example.
2 Likes
I do use those, but the Package Evaluator seems to only be run infrequently, like once a month?
I’ll be stealing whatever I can from your README! (you know that’s the best form of flattery 
)
Package Evaluator runs them pretty frequently (I think every day (at least for nightly) and whenever a change is registered). If nothing changes, it shouldn’t change the status. Not sure if it runs when a dependency registers a change too. Please do, I am running a project about open-source software and good practices makes it so much better. Finalizing the package status for Julia packages analysis.
It must just be that pkg.julialang.org doesn’t update that frequently.
I’m waiting for some newly registered packages to show up 
How many days have those been in METADATA.jl?
The badges that I link to show old releases of the packages (v0.2.0, instead of v0.2.3, from 7 days ago, for example), and some badges aren’t available yet (get 404), 12 days after being registered (CharSetEncodings.jl).
It also says that the pulse was last updated 5-14-18.
I’ve been trying to use the shields from https://shields.io/, however, they usually don’t show up when I put them in my README.md (it’s a random sort of thing), and when I put them here, it takes a long time for them to display.
Strs
Julia
I also want to figure out how to get the version information for Julia master (at least, the last nightly), not just the last released.
Thanks for all the pointers!
Unsure about the delay. Do you want the version of the nightly or the last nightly binary available? For the nightly ones, you could scrape https://julialangnightlies-s3.julialang.org/. For the last commit, (build from source) the Github repo and a short script that I always forget. Still, that might just be relevant for a few months before 1.0.
For the shields, if you are using custom ones, make sure that they are easily scrapable / machine readable.
What I’d really like to be able to display, is the nightly version of julia used for the tests of my package when it passed or failed to build. Not sure how I’d get that.
Barring that, just the last nightly binary available.
How does one make a shield easily scrapable / machine readable?
This is all new to me, like a shiny toy!
That you get from the Travis C.I. API, but probably is it really worth it? It will be changing pretty much every day so it will be identified by the nightly and time-stamp. You can use the the link provided for the latest nightly binary distribution. For now, I would just test against julia 0.7-alpha until julia 0.7-beta or a release candidate.
For the shields to be machine readable, it depends on the shield, but if it is widely used and well defined scrapers should be able to determine the value easily. For example, using markdown and good HTML5 / CSS3+ tags.
After playing with how all this looks for a while, I’ve decided that I really don’t want badges in the “Dashboard” display I’d like to have for all the packages in JuliaString.org (which right now, is essentially in the Strs README),
instead, simply green or red checkmarks for the failing / passing build status, in a matrix with columns for Windows 32-bit, Windows 64-bit, Linux x86-64, MacOS [and hopefully ARM 32, ARM 64, and POWER in the future if I can find free CI testing platforms for those that handle Julia], with results for stable and nightly Julia, and last release / master of each package, and display the version string and date (as MM/DD/YY) for the last release of each package.
Have any suggestions? I’m not a front-end guy, this is all too new to me! Thanks for all the help already!
You could file an issue for a Feature Request with PackageEvaluator. I believe that would be the most suitable place to develop what you want. In general, most packages aren’t OS/infrastructure dependent so is not a big deal for most package under the most likely scenarios. Currently, PackageEvaluator displays the status based on independent run test matrices for registered packages at Julia Ecosystem C.I.. The default statistics are all current (i.e., maintained) releases of the language and nightly using Linux.
I think what you want is somewhat similar to CRAN’s C.I. matrix,
ggplot2 C.I.
Similar, but prettier than that , with nice green and red checkmarks in the grid for passing and failing.
I have seen a lot of places where people simply aren’t aware that their packages don’t work on 32-bit (Windows or ARM), or any Windows.
After I got Appveyor working, I saw that there were some 32-bit and Windows issues, which I’ve been trying to fix, but for that, I want to have a dashboard such that anybody can quickly see if the packages will run on those platforms.
32-bit infrastructure is almost exclusive to Windows these days. While the number of users is still significant (mostly outside the developed or Western nations), for many sophisticated applications you wouldn’t be using 32-bit infrastructure (e.g., scientific computing). You could invest effort to support a wider array of configurations, but that takes away from resources to maintaining and developing projects for your core users. CRAN, for example, only tests 64-bit Linux, Mac OS, and Windows.
I actually don’t care about 32 bit Windows systems, but rather 32 bit ARM Linux systems, such as the $35 Raspberry Pi.
My packages tend to be low level, just the sort of thing you might want on your Pi