AUTHOR ARCHIVES :
Travis CI — использование с проектами на Github
Travis CI это серверная платформа непрерывной интеграции, которая является бесплатной для всех проектов, с открытым кодом, размещенных на Github. С помощью всего лишь одного файла .travis.yml
(содержащим информацию о проекте), возможно активировать автоматические сборки.
В данном примере Travis CI использует следующие инструменты:
Интерфейс Travis CI
Давайте разделим главную страницу Travic CI, на логические блоки.
- Боковая панель: отображает, список проектов, у которых в данный момент проходит автоматизированная сборка. В каждом процессе отображается название проекта, продолжительность и порядковый номер сборки.
- Build in Progress [желтый]: указывает, что проект в процессе CI.
- Build failed [красный]: указывает, о не успешном завершении процесса.
- Build passed [зеленый]: указывает, о успешном завершении процесса.
- Название проекта: Заголовок в формате имя пользователя / хранилища. Символ Octocat и ссылка на Github, репозиторий, содержащий исходный код.
- Информация о сборке: отображается информация по текущей сборке, история сборок, сборки от pull request.
- Build Matrix: отображает информацию о каждой из задач.
Статус сборки
К вашему проекту возможно подключить динамический индикатор статуса. Собрать URL изображение можно по такому шаблону — http://travis-ci.org/[username]/[repository-name].png
Ресурсы Travis CI
Вот некоторые ресурсы для понимания концепции непрерывной интеграции, а также обучения и интеграции Travis CI в ваши Github проекты:
- Непрерывная интеграция Мартин Фаулер
- Travis CI документации и блог
Самый быстрый и простой способ узнать различные конфигурации для .travis.yml
файл — обратить внимание на популярные проекты, которые уже используют Travis CI. Вот некоторые из них:
- Ruby on Rails (Ruby)
- BackboneJS (JavaScript)
- Composer (PHP)
- Flask (Python)
Надеюсь, этот небольшой обзор дал вам краткое понимание, как можно легко и быстро интегрировать Travis CI в ваши Github проекты!
JsHamcrest (“match” rules)
JsHamcrest для Javascript! Поддерживает интеграцию со всеми топовыми тестовыми фреймворками!
Github: https://github.com/danielfm/jshamcrest
Daniel Martins, +1 за сборку проекта и генерацию документации через python 🙂
Falcon 2.0 to Actionscript 4.0
Итак, удалось перехватить кое-что любопытное из переписок … 🙂
Falcon/ASC 2.0 was the starting point for Adobe’s
development of an AS4 compiler.
http://www.mail-archive.com/flex-dev@incubator.apache.org/msg13224.html
ASC 2.0: http://www.bytearray.org/?p=4789
I don’t think Adobe has publicly disclosed details about AS4 yet, so I’ll just
say that there are significant changes from AS3. However, porting Flex would
probably involve more work in adapting to the new runtime APIs than in adapting
to the new language.
Also, the AS4 compiler will not be open source.
http://www.mail-archive.com/flex-dev@incubator.apache.org/msg13197.html
ASC is already moving to ASNext targeting the
next generation runtime which is targeting game developers.
The rendering architecture of the new runtime is Stage3D only. So
essentially, there is no «native» DisplayObject.
So your framework needs to leverage Stage3D, just like iOS is
leveraging OpenGL for their components UI.
That’s why we have been funding Starling to help people transition to
a full Stage3D model.
http://mail-archives.apache.org/mod_mbox/incubator-flex-dev/201210.mbox/%3C149F8129B58B2D418508E63117D9C5419B5AEB2A92@nambx05.corp.adobe.com%3E
> The question is what amount of work does it require to port from AS3 to
> AS4 ?
Significant. AS4 has made no promise to be backward compatible with AS3.
http://www.mail-archive.com/flex-dev@incubator.apache.org/msg13198.html