If anyone missed it (like I did), it’s worth noting due to my ultimate laziness:
When you enter “Fixes #45” into a commit message, issue #45 is closed once that commit is merged into your default branch. If the bug isn’t fixed in your default branch, the issue remains open. Once the commit with the fix is merged into your default branch, the issue is automatically closed.
If you make a commit in a non-default branch with the “Fixes #33” syntax, the issue is referenced with a tooltip.
You can use any of the following keywords to close an issue via commit message:
Somehow, this project passed me, even though the idea is quite good!
Certainly, you won’t make your living with it (but who knows!), but it might show you (and others) whether you work is appreciated in the open source community and motivate other developers whose work you support!
Vendor prefixes for properties, functions, @-rules and even full declarations are automatically generated – based on trustedsources – so you can maintain cross-browser support while keeping your source code clean and easy to maintain.
I guess it’s time to do some sort of benchmarking and evaluation on test automation we started to use recently in the company.
*Captain Obvious mode on*
For those companies/developers that still haven’t figured out what’s test automation (front-end/back-end, TDD, BDD, etc) and continuous integration – guys, you’re doing it wrong. Yeah, I know, I know that “everything works fine for us and there’s no need to waste more money for things we don’t use”. By the end of the day it’s your time you’re spending on doing things we stopped doing at all focusing on more important things.
Here, I should’ve started explaining you that CI is a money saver in complex projects, when you can iterate faster with production systems increasing the responsiveness of your product/service. Setting up CI infrastructure and pipelining the project/task management is closing down the topic of “D-days” for the projects and all that pressure on the team once you release.
But, I’m pretty sure that you all know about that!
*Captain Obvious mode off*
Coming back to some basic comparisons on Travis and Circle, you won’t find in this post a massive judgement on what’s better. Working with WHMCS-API gem I’ve used Travis-CI for test automation.
Stating that Travis and Circle are interconnected with Coverall, GitHub, Zapier, Asana, and other great services – out of comparison list. It’s just there – live with it and be happy!
Speed performance fully depends on the type of tests you have and level of their complexity. Comparing Ruby gems we test on Circle and Travis – I’d recommend Travis – config file is few lines shorter. Comparing the list of supported languages, platforms – definitely Travis, but I guess it’s the matter of time when Circle gets there.
What was chosen for the next few quarters:
Travis-CI remains for now a a service where we release our open-source projects to do the tests and CI in the company
Technology we use is fully supported by both – thus services can be swapped any time.
Task management is streamlined from “Task given” to “Task deployed, tests ran, check the diff and deploy once feel like it”.
Next time I’ll grumble about something less tech’y.
Joshua Priddle did a great job back in DotBlock accomplishing Ruby binding for WHMCS API. Unfortunately, last signs of activity were 3 years ago. It’s a pity, as gem is great, and works like charm, but it became massively outdated, and piled with pull requests no one merged in the master branch for ages.
The code was published by MIT license on 2011, thus whmcs-api gem will be its descendant, which I’ll try to keep updated as much as possible.
For now it’s being tested on Ruby 2.x and WHMCS 5.3.x without any problems. The source code and any issues are better be reported on the Github repo.