Weblog

How to enable Travis CI for an extension John Muhl

This information is also available on the wiki where it will receive updates as needed.

Travis CI is a flexible and easy to use continuous integration server; see the Getting Started page for more details. The flexibility means that there are any number of ways to setup and test your extensions. Here is one way.

First you need to add a .travis.yml file to the root of your repository.

rvm:
  - 1.8.7
  - 1.9.2
  - 1.9.3

before_script: "./spec/ci/before_script"

script: "./spec/ci/script"

env:
  - RADIANT_VERSION=0.9.1 DB=mysql
  - RADIANT_VERSION=0.9.1 DB=postgres
  - RADIANT_VERSION=1.0.0 DB=mysql
  - RADIANT_VERSION=1.0.0 DB=postgres

notifications:
  recipients:
    - you@example.com

The rvm array shows the Ruby versions you want to test against; since Radiant 1.0 supports the three latest Ruby releases your extension should too. Likewise the env array list Radiant version/database combinations to test against; the Radiant version can be any tagged version of Radiant.

Next up we need to create the before_script referenced above. The before_script is run before your tests and sets up a complete Radiant environment within which your tests will be run.

cd ~
git clone git://github.com/radiant/radiant.git
cd ~/radiant
if [[ $RADIANT_VERSION != "master" ]]
then
  git checkout -b $RADIANT_VERSION $RADIANT_VERSION
fi
cp -r ~/builds/*/YOUR_REPOSITORY_NAME vendor/extensions/YOUR_EXTENSION_NAME
gem install bundler --pre
bundle install

case $DB in
  "mysql" )
    mysql -e 'create database radiant_test;'
    cp spec/ci/database.mysql.yml config/database.yml;;
  "postgres" )
    psql -c 'create database radiant_test;' -U postgres
    cp spec/ci/database.postgresql.yml config/database.yml;;
esac

bundle exec rake db:migrate
bundle exec rake db:migrate:extensions

Replace YOUR_REPOSITORY_NAME and YOUR_EXTENSION_NAME in the before_script with the actual name of your repo and extension; e.g. radiant-sheets-extension and sheets respectively. Don’t forget to make this script executable before committing it to your repository.

Finally we need to create the script file. This is the script that actually executes your tests.

cd ~/radiant
bundle exec rake spec:extensions EXT=YOUR_EXTENSION_NAME

Again you need to replace YOUR_EXTENSION_NAME with the real thing and make the script executable.

All that’s left to do is login to Travis, enable the commit-hook for you repository and push. Head over to http://travis-ci.org/ and click the “Sign in with GitHub” link. Once you’ve authorized through GitHub visit your profile page on Travis, find the extension to enable and flick the switch to on.

Now you’re ready to commit and push the .travis.yml, before_script and script files and let Travis handle the rest. If you want to know more about all the options you have with Travis the documentation is very good. You can see an example of this setup in action on the Sheets extension or check out what it looks like to have your specs run by Travis by visiting the Travis page for Sheets. Once setup Travis will run your tests after every commit unless you add [ci skip] to the commit message (which is good practice when pushing documentation or other commits that don’t affect functionality).

Radiant 1.0.0 Release Candidate 4 Jim Gay

Radiant 1.0 is almost here. Release Candidate 4 has been pushed to rubygems.

Thank you to everyone that’s been helping out with this release.

If you’ve got a site or extension, please begin testing against this release. As always, report any problems or feature requests at https://github.com/radiant/radiant/issues

gem install radiant --pre and you’re on you way!

The installation instructions are at the wiki with a link to a gist where I’ve been recording a step by step process for upgrading from Radiant 0.9.1

Additionally, John Muhl has been doing a fantastic effort in documenting the installation from scratch for Ubuntu Mac OS X and we’ll be updating instructions for Windows and Gentoo.

There’s a lot thats new, too much to cover here, so look for more blog posts about the new features.

Radiant 1.0.0 Release Candidate 2 Jim Gay

Thank you to everyone that’s been helping out with this release.

If you’ve got a site or extension, please begin testing against this release. As always, report any problems or feature requests at https://github.com/radiant/radiant/issues

gem install radiant --pre and you’re on you way!

Benny Degezelle is on the Radiant Core Team Jim Gay

Please reach out to Benny Degezelle and say “thanks.”

Benny Degezelle is a member of the Radiant Core Team. He’s been a long time supporter of Radiant and has created or contributed to many extensions and has even more hot code at github.com/jomz

Send him some “thank you”s on Twitter at @jomz

Radiant 1.0.0 Release Candidate 1 Jim Gay

Announcing the first release candidate of Radiant 1.0.0.

The final 1.0 release will be the last on Rails 2. After that we’ll be focusing on moving forward with the rails framework.

There are a couple of changes that are worth mentioning, but see the CHANGELOG for the full details. What are some big changes?

If you are an extension developer, begin upgrading now. The official release of 1.0 is just around the corner.

As always we welcome your feedback and contributions.

Download & Install

You can download the gem here http://github.com/radiant/radiant/downloads

Install it with the gem command:

$ gem install radiant --prerelease

This will install the gem as ‘radiant-1.0.0.rc1’.

How to Upgrade an Existing Project or Site

1. Update the Radiant assets from in your project:

rake radiant:update

2. Migrate the database:

rake production db:migrate

3. Restart the web server

RadiantCasts episode 25 - Radiant As A Blog - Part 3 - Adding Tags Cristi Duma

In part three of Radiant As A Blog, you'll see how to use and configure the Tags Extension, to add tagging functionality to Radiant.

Content

Resources

Cristi Duma is a software engineer at Aissac.

Radiant 0.7.2 - Engravings Retro Release (bugfix) Andrew vonderLuft

Radiant 0.7.2 Engravings is a simple bugfix release, recommended for developers using 0.7.1, who write or run specs.

We have discovered a very remote edge case when running specs, that if the default Cache directory, ResponseCache.defaults[:directory], is explicitly set to blank or nil, the cache directory is interpreted as ‘/’ and thus clearing the cache in your spec triggers the execution of `rm -rf ‘/’`.

Upgrading an existing project/site from 0.7.x

1. Update the Radiant gem:

% gem install radiant -v 0.7.2

2. Change the RADIANT_GEM_VERSION constant in config/environment.rb to “0.7.2”.

3. Restart the server

RadiantCasts episode 24 - Radiant As A Blog - Part 2 - Adding Comments Cristi Duma

In part two of Radiant As A Blog, you'll see how to use and configure the Comments Extension, to add blog-like comment functionality to Radiant.

Content

Resources

Cristi Duma is a software engineer at Aissac.

Paths and URLs Jim Gay

At the heart of Radiant’s Page model has been the find_by_url method.

It takes a path, and finds the proper bit of content to display. I wrote a detailed explanation of how find_by_url works on my blog.

In the future things like this will be changing. Our url and find_by_url methods and their ilk haven’t truly had anything to do with URLs, but with paths. So we’re fixing that. The next release will refer to “path” where “url” used to be but don’t worry, everything will work just as you expected if use the current url methods.

To get the same behavior, you’ll need to use methods like path or find_by_path since that’s what you’re really after. This commit shows some of the changes that are upcoming. For now, everything will work the same. We’ve aliased the methods for the next release of Radiant so that your page’s url and path are the same. But they won’t be the same in subsequent releases.

A url method will return an actual URL such as http://radiantcms.org/blog instead of just /blog. We have an open issue related to this at github which describes the same thinking laid out here.

If you’re running on edge, start your switch now.

Design first philosophy Jim Gay

Radiant has always taken the design first approach to the user interface. Did you know that we use a really simple and easy to use prototyping project at http://github.com/radiant/radiant-prototype

It’s where we work out ideas for the application before we need to put much effort into the code. This has been done for a long time, but most people don’t know about it. We’ve decided to make it easier for everyone to see and understand. Take a look at it in action at http://prototype.radiantcms.org/

Any time there is a push to the main prototype project, it’ll show up at the prototype site.

Andrew vonderLuft Joins the Core Team John W. Long

Andrew vonderLuft of AVLUX has officially joined the core team as our resident Sys Admin. Andrew’s been serving in this capacity for a long time now so we thought it fitting to give him rank and title!

Seriously, I can’t say enough about how much Andrew has contributed by managing the Radiant infrastructure. When AVLUX first took over the hosting for the project Andrew and his team managed the complicated transition from our old servers to the new and made it as seamless as possible. At the time this was no easy task because we were running a custom install of Trac, our own Subversion repository, and our own mailing lists — not to mention our custom install of Radiant for the main website. Since that time we’ve moved over to Google and GitHub and we’ve added the extension registry. Andrew and his team have been there every step of the way.

So thank you Andrew! Thank you for your tireless efforts on behalf of the Radiant community. And welcome to the team!

RadiantCasts episode 23 - Radiant As A Blog - Part 1 Cristi Duma

Part one of a series of episodes where you'll see a quick rundown of extensions and techniques that can used to publish blogs with Radiant.

Content

Resources

Cristi Duma is a software engineer at Aissac.

RadiantCasts episode 22 - Sphinx Search Extension Josh French

Thinking Sphinx is a popular choice for easily adding powerful, full-text searching to Rails applications. Find out how the Sphinx Search extension can bring the power of Thinking Sphinx to your Radiant sites in this screencast. We'll install the Sphinx Search gem, create a search form and results page, and discuss some advanced options.

Content

Resources

Josh French is the senior engineer at Digital Pulp.

Continue Reading…

Manage CSS and Javascript from the Admin UI Jim Gay

Yesterday I committed a new core extension to Radiant: Sheets

With this new feature you can manage stylesheets and javascripts from the admin interface, but before I get into the details of it you should be aware that if you don’t want this feature, you can simply prevent it from being loaded with:

config.extensions -= [:sheets]

What is Sheets?

Sheets is a way to manage stylesheets and scripts from your existing page tree. With Sheets, you’ll create new types of pages: JavascriptPage and StylesheetPage.

Pages of these types are Sheets.

The basic features:

Differences with other solutions and the benefit of using Sheets

Some standard site templates provided by Radiant include stylesheet content in a typical page. This requires a custom layout merely to set the content type, and displays content unintended for editing by typical users. This makes for a cluttered page index view and cluttered layout index view.

A popular solution to these problems is the SNS extension . SNS separates the editing interfaces for these types of content, but the problem is that it makes too much of a separation. With SNS, stylesheet and javascript content is stored in a separate table and is generated by models completely unrelated to the Page model. This means that other extensions are required to do extra work to provide features and Radius tags to SNS content, and as a result many extensions do not do this work. This situation makes for a confusing introduction to Radiant for new users and developers alike.

You can get around this SNS limitation by using the SNS Page Hook extension but even this solution will lead to unpredictable results because it merely copies modules from the Page model to the TextAsset model and tricks the included methods into believing they are operating on a Page. But this is not a good long-term solution.

Sheets keeps this content in the same location as all other content: Pages. Doing it this way allows any chosen URL or Page slug to be protected properly with newly created pages. Even more importantly, this allows user and developer expectations about the behavior of Radius tags to make sense. With Sheets, extensions which add Radius tags to the Page model add them to stylesheets and javascripts too; there is no extra work to be done.

Not only does it do all this, but the standard Page model provides a headers method which Sheets overrides to alter the mime-type for the returned content. Sheets uses the built-in ways to serve content, rather than generating yet another way to serve content like SNS.

Extra features

By default Sheets has a SassFilter for text and since Radiant depends on (and includes) Sass, you’ll always have that available. But the SassFilter is just a regular TextFilter like the ones used on pages so I had to do some work to ensure that you wouldn’t be able to filter your typical Page content with Sass.

The SheetsExtension has 2 accessors: stylesheet_filters and javascript_filters.

You may manipulate the contents of these variables with your added text filters. You could write an extension to provide a Less filter:

SheetsExtension.stylesheet_filters << LessFilter

In the future, it will probably be a good idea to move these accessors off of the SheetsExtension itself and onto the ApplicationController so that you don’t need to worry about extension load order to add a text filter.

Currently, there is no interface element to alter the path from where your site will pull content. CSS is pulled from /css and Javascripts are pulled from /js. SNS was standardizing this approach because changing this setting required running rake tasks and not merely changing a simple setting. With Sheets, the path is determined by a page slug so in the future we’ll have a way to change that location to /whatever-you-want (but if you really want to do it now just jump in the console find the css or js pages and change their slugs).

I will be providing the ability to migrate your content from SNS to the page tree in some way (be it in the Sheets extension itself, in SNS, or some other migrator extension).

I still need to write some specs and cucumber features but I wanted to get this out in the wild to get feedback, so please leave your complaints or praise here.

Reasons for the change from SNS

Aside from the reasons I’ve listed above I could only see more difficulty down the road in getting TextAssets to behave the way you’d expect. I’ve been committing a lot of changes to SNS and recently wrote the SNS Page Hook extension to deal with these problems.

In previous versions of SNS and Radiant, the SNS approach made sense. It setup a separate ResponseCache to serve stylesheet content and javascript content from separate locations. And it completely separated those TextAssets from your page tree which makes a lot of sense for users, but developers who have worked with SNS have expected to be able to use any radius tag in the system and they couldn’t.

If you’re a user of SNS, I really think you’ll like the change to Sheets.

RadiantCasts episode 21 - Radiant 0.9 Refraction Release Cristi Duma

A few weeks ago Radiant 0.9 was released. I'm sure you saw it, and if you watch Radiantcasts, you saw Radiant 0.9 in action. This episode outlines some of the best features this release brings.

Content

Resources

Cristi Duma is a software engineer at Aissac.

RSS Feed | Weblog Archives | Comments powered by HaloScan