Question: will this project be deprecated in favor of PlatformIO? #16
Comments
|
Yes, no additional dependency (PlatformIO) and closer to "original" Arduino builds. |
|
Are you saying that you evaluated PlatformIO for your purposes and found it to be lacking, or that you are satisfied with the solution you have? Side question, how are you running these CI scripts from your local machine prior to pushing code to github? On OSX, the only practical thing I could do was read through |
|
Personally I use both PlatformIO and travis-ci-arduino. When I want to test that something compiles well on Arduino, I use travis-ci-arduino. I am not running these CI scripts from my local machine. |
|
Hmm. Does this imply that you've noticed instances where PlatformIO passes but travis-ci-arduino fails? |
|
No, but I didn't really compare. |
|
It turns out that PlatformIO is a paid service and not a freely available program. I've submitted a pull request to Travis CI to update their docs accordingly. |
|
FYI we just fixed some bugs, if you haven't had success - it should all be working now thx! |
|
It's not that I haven't had success... it's that this script doesn't allow for unit testing. I am porting the CI idea from your I'd love your comments in a week or so when I get this into a more stable state. Would a CI + unit testing script (inspired by the same "use one script everywhere" design of this repo) be of interest to you? |
|
ive never used ruby so cannot test, but if you have a PR that doesn't change around the original install.sh plz submit a PR! |
|
Unfortunately, mine (https://github.com/ianfixes/arduino_ci) is different from # .travis.yml
sudo: false
language: ruby
script:
- bundle install
- bundle exec arduino_ci_remote.rbYou need to add a source 'https://rubygems.org'
gem 'arduino_ci'And that's basically it -- a YAML file controls the rest. A working example of a CI-enabled Arduino project would look like this: Most notably (and the point of this whole exercise), you can unit test your library with files like this: #include <ArduinoUnitTests.h>
#include "../Queue.h"
unittest(empty_queue)
{
Queue<int> queue(5);
assertEqual(0, queue.count()); // initially empty
assertEqual(0, queue.peek()); // 0 happens to be the default int val
assertEqual(0, queue.pop()); // popping when empty also returns the default
assertEqual(0, queue.count()); // still empty
}
unittest(fill_and_empty)
{
Queue<int> queue(5);
queue.push(11);
queue.push(19);
queue.push(44);
assertEqual(3, queue.count());
assertEqual(11, queue.pop());
assertEqual(19, queue.pop());
assertEqual(44, queue.pop());
}
unittest_main()
Example output from a CI job (https://travis-ci.org/ianfixes/Arduino-Queue.h/builds/333540256#L522): (snip) |
|
@ladyada I wanted to follow up on this. What I wrote is a feature-complete replacement for your
Then, I added the following features that you might find useful:
I've submitted adafruit/Adafruit_FONA#91 to show how my system works in practice, the results are here: https://travis-ci.org/adafruit/Adafruit_FONA/builds/350489990 Relevant portion: Are there any features I'm missing? |
|
sounds cool - we've got 1000 github repos so not sure when we'll get to implementing this but next time we do a FONA sweep we will check it out :) |
|
(thanks for writing it - it looks really nice!) |
|
Assuming that I could write a script to automatically convert over each repo ( Also, I'm happy to move this discussion if you can recommend a more appropriate forum. (For future searchability I'm adding this link to the other issue: #20 ) |
|
/me thinks can we merge in your project as an alternative install script? like people can choose which they prefer - i want to include it for others even if im not quite ready (i dont know ruby so maintenance would be tough) |
|
Aah, I'm giving off the wrong impression here! What I'm really asking is "if you close your eyes and imagine the perfect CI script (and you could wave a magic wand to have it), what features would it have?" Regarding an "alternative install script", that should be straightforward. I will set up a PR on https://github.com/adafruit/Adafruit-WS2801-Library that demonstrates both CI pieces running side by side and link it here. |
|
ideal CI would be super fast, thats the most important thing we've found :) everything else is pretty easy to set up! |
|
Can you enable CI on https://travis-ci.org/adafruit/Adafruit-WS2801-Library ? I'm setting up the demo in this PR: |
|
enabked! |
|
Out of curiosity, when you say that you want it to be "super fast", is that because your only way to test your changes is with Travis (and not your local machine)? |
|
because it has to run on every commit and PR. if it takes a long time, and there's an error, the author has to check back and fix it. people will not run CI locally! |
|
I've completed this work. adafruit/Adafruit-WS2801-Library#21 demonstrates both CI methods running in parallel jobs. Speed considerationsThe execution time seems to vary widely. In this job the two scripts take roughly the same amount of time to complete. In this job, You should check the logs to make sure I'm accurate on this, but I believe the same set of platforms and examples are being verified for both scripts. I temporarily disabled Travis' caching to make it a fair assessment.
Unit test considerationsWithout adding significant time to the build, here is
A detailed analysis of the problem is easier to see using the OSX version of It should be noted that jobs take considerably longer to run on OSX. I'd be glad to find a compiler flag that will offer the same support on a Linux host. Hope this is useful! |
|
thanks, we do use caching quite a bit to speed up CI's FYI! |
|
Yup, disabling the cache was only to accurately measure the run times between the two scripts. I would expect to re-enable it along with any other pull request comments you have. |
|
Sorry in advance for email spam, I will be copying portions of this discussion to #20 as the more relevant issue |
I'm trying to set up a template for Continuous Integration of Arduino library code (both compilation and unit tests), using Travis CI.
A Google search led me to
travis-ci-arduinoas one of the best examples of how to do the "does it compile" test on Travis. However, it looks like PlatformIO is what Travis recommends for this:https://docs.travis-ci.com/user/integration/platformio/#Examples
Are there advantages to using this method instead of PlatformIO?
The text was updated successfully, but these errors were encountered: