AUTHOR ARCHIVES :

Travis CI — использование с проектами на Github

Travis CI это серверная платформа непрерывной интеграции, которая является бесплатной для всех проектов, с открытым кодом, размещенных на Github. С помощью всего лишь одного файла .travis.yml (содержащим  информацию о проекте), возможно активировать автоматические сборки.

В данном примере Travis CI использует следующие инструменты:

Интерфейс Travis CI

Давайте разделим главную страницу Travic CI, на логические блоки.

travis-interface

  1. Боковая панель: отображает, список проектов, у которых в данный момент проходит автоматизированная сборка. В каждом процессе отображается название проекта, продолжительность и порядковый номер сборки.
  2. Build in Progress [желтый]: указывает, что проект в процессе CI.
  3. Build failed [красный]: указывает, о не успешном завершении процесса.
  4. Build passed [зеленый]: указывает, о успешном завершении процесса.
  5. Название проекта: Заголовок в формате имя пользователя / хранилища. Символ Octocat и ссылка на Github, репозиторий, содержащий  исходный код.
  6. Информация о сборке: отображается информация по текущей сборке, история сборок, сборки от pull request.
  7. Build Matrix: отображает информацию о каждой из задач.

Статус сборки

К вашему проекту возможно подключить динамический индикатор статуса. Собрать URL изображение можно по такому шаблону — http://travis-ci.org/[username]/[repository-name].png

travis-build

Ресурсы Travis CI

Вот некоторые ресурсы для понимания концепции непрерывной интеграции, а также обучения и интеграции Travis CI в ваши Github проекты:

Самый быстрый и простой способ узнать различные конфигурации для .travis.yml файл — обратить внимание на популярные проекты, которые уже используют Travis CI. Вот некоторые из них:

  1. Ruby on Rails (Ruby)
  2. BackboneJS (JavaScript)
  3. Composer (PHP)
  4. Flask (Python)

Надеюсь, этот небольшой обзор дал вам краткое понимание, как можно легко и быстро интегрировать Travis CI в ваши Github проекты!

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