Can we add and status badge?

Issue #133 new
Nathanael Jones
created an issue

While I can set up for my own fork of gd-libgd, does not let me set up CI for the official repo (I assume because I lack push permissions or something).

It takes about 5 minutes to set up on a repository. Once that is done, I would like to add a readme file and a status badge so it's obvious when the build gets broken.

Comments (33)

  1. Nathanael Jones reporter appears to be abandoned; their VMs are broken and spewing errors. I can set up AppVeyor, but if you want reliable linux/mac builds and artifacts, we'd have to move to github. (Travis is github-only)

  2. Nathanael Jones reporter

    Travis uses GitHub's authorization system to determine who can do what. This makes it very easy to manage projects, as you only have to manage permissions in GitHub. When you're using advanced services that require encrypted tokens (like releasing artifacts to github releases, or coverity scan, etc), this is very nice.

    The upside, Travis+GitHub is a super-smooth, fast, experience. It's open-source and the best-maintained CI service I've seen.

    The downside, it is tied to GitHub. GitLab compatibility might be possible, but the design is intentionally married to GitHub.

    Most paid CI services advertise 'travis.yml' compatible. I'm paying $80/mo for AppVeyor, but Travis is so fast - and free - that I'm not inclined to pay for or something similar knockoff when I can get the real thing.

  3. Nathanael Jones reporter

    It wouldn't automatically test every pull request, which (to me) is a big feature. (also; one of those things that you can only do when you tightly integrate with the git provider, like travis does).

    I really like bitbucket, but GitHub's giant ecosystem has strong gravitational pull. It does also have really good multi-factor authentication, which I promote the use of.

    There's also the convenience factor; if libgd was on GitHub, we would sync our copy much more frequently, since it takes seconds via browser (instead of minutes via commandline), and we could easily view changes between branches on different repos. Right now, we usually end up with a painful rebase before each upstream push :[. That does discourage PR frequency.

    I'd also like to invest in a '' file eventually; this (on GitHub) is displayed to users filing issues or PRs, so that they can keep code style, etc. consistent. Making the onboarding process easier and getting more devs to jump in would be nice; as would setting up and marking tasks as 'up for grabs'. (Example on ImageResizer) But this too, is GitHub specific.

    Mirroring is certainly better than nothing, though!

  4. Pierre Joye

    hm... That's bad.

    I am not too keen to do yet another move. While github is very appealing, I do not have the time to transfert everything, keep history (git) and all that :/

    Any suggestions welcome :)

  5. Ondřej Surý

    Converting the repositories is easy - e.g. done.

    Now I am working on build of the pelican website (I wouldn't mind converting the pages to native github Jekyll... but I am not doing that :)).

    The next step would be to:

    1) setup CI build at (easy, I will do that as soon as I finish the website) 2) setup Coverity build from (and drop the custom jenkins at CZ.NIC) 3) setup push mirroring over to bitbucket (should be fairly easy) 4) change various information on the website, etc.

  6. Ondřej Surý

    So, website is up and running on You can either setup alias from (there should be a CNAME file in website root) or just do the redirect.

    Travis CI on libgd fails with something webp related. Perhaps the setup is missing some library. I also changed .travis.yml to use autotools on linux.

  7. Nathanael Jones reporter

    Add tostercx to the repo, he can fix the build. A few important commits didn't make it upstream after we updated some dependency locations, thus the issues. My github is nathanaeljones.

  8. Nathanael Jones reporter

    Re: issue migration, this is a problem on the bitbucket/read side, right? A hacky fix would be to transfer the repo to an individual, then back to the org (assuming bitbucket permits that).

  9. Nathanael Jones reporter

    It looks like the rate limits don't apply to private repos. Making the repository private (temporarily) during the import should make this possible. It would also prevent @notifications from happening to everyone, which is annoying.

    I just completed a test against a blank private repo and all 140 were migrated. If someone can give me Owner access, I'll use my card to enable private repos, and get this done.

    @Ondřej Surý @Pierre Joye

  10. Log in to comment