-
Notifications
You must be signed in to change notification settings - Fork 8
How do we know a project **should** have CI? #32
Comments
I think you should check for a CI Badge, and leave it at that. There should be a CI badge on all relevant repos, at this point. |
Sometimes the text is different. This makes it easier to check. I suppose we could standardize that text - should have done that earlier. See #32
Regarding Travis and 'build unknown', Getting a better button seems harder than I expected. For now, let's just leave it as it is. Rethinking the CI; Do the tests fail if there are no tests set up? Should we test everything? |
Probably not. We have a lot of random repos, eg: https://github.com/ipfs/POST |
Those can be cleared out by searching for 'discussion repo' badges, which I should have added to all of them. |
We only really need to check for the link, not for the full markdown. Some repos are displaying this differently - for instance: ipfs/station: [![Build Status](https://img.shields.io/travis/ipfs/station/master.svg?style=flat-square)](https://travis-ci.org/ipfs/station) ipfs/js-ipfs: [![Travis CI](https://travis-ci.org/ipfs/js-ipfs.svg?branch=master)](https://travis-ci.org/ipfs/js-ipfs) Both should be caught. This commit allows this possibility, and we see more coverage on the project-repos board. Related to ipfs-inactive#32.
OK. Can we check for code in a repository using https://github.com/github/linguist, and then automatically disqualify all non-code repositories? Everything else should have CI or Travis, right? |
Or could we just search for a .travis.yml or a circle.yml and leave it up to the project heads to make sure that these exist? |
👍 this sounds perfect. Maybe language is in the repo object returned by Octokat?
👎 I don't think so... part of the idea of this project is to watch all the repos and make sure they are all following our guidelines... |
Boom! It looks like that is in the language object returned by Octokat. For We should also check in case there is a .travis.yml or circle.yml, too: for instance, ipfs/awesome-ipfs has no code, but I have travis running to make sure that links aren't broken in any PR. |
Awesome. So if no CI is found, we leave the CI column blank for language=>null repos, but put a "CI missing" badge in if language=>something. |
@RichardLitt said in #25 (comment):
The two Travis colums are actually different... One is the build status, and one is whether the Travis badge is in the readme.
Better button text sounds fine, feel free to PR, preferably with similar styling to the buttons, and probably grey color.
Since, as you point out, CI is not needed on all repos, we should not turn the latter column red, if there is no CI at all. Unfortunately, this looks roughly the same as a project that has code and tests but has set up zero CI, which we would like to "mark red".
We could say if it contains code (JS, go, rust, etc) it needs CI, and mark it red if it has none. This may be a bit of work ; )
Thoughts?
Should all repos that contain code have CI?
The text was updated successfully, but these errors were encountered: