galaxy

I maintain a large number of Ansible Galaxy roles, and publish hundreds of new releases every year. If the process weren't fully automated, there would be no way I could keep up with it. For Galaxy roles, the process of tagging and publishing a new release is very simple, because Ansible Galaxy ties the role strongly to GitHub's release system. All that's needed is a webhook in your .travis.yml file (if using Travis CI):

For collections, Ansible Galaxy actually hosts an artifact—a .tar.gz file containing the collection contents. This offers some benefits that I won't get into here, but also a challenge: someone has to build and upload that artifact... and that takes more than one or two lines added to a .travis.yml file.

Until recently, I had been publishing collection releases manually. The process went something like:

The following is a transcript of the content in my AnsibleFest Atlanta 2019 session, There's a role for that! How to evaluate community roles for your playbooks.

• Presentation slides
• Presentation video

Introduction

I'm Jeff Geerling, I wrote a book on Ansible (Ansible for DevOps), I have used Ansible on an almost daily basis for hundreds of different projects since 2013, and I now work with Red Hat's Ansible team as a technical contractor.

Some people wonder ask how teams can be productive while maintaining many applications on a variety of cloud providers. One of the key reasons is reliance on Ansible content contributed and maintained by others.

Every few weeks, when some of my automated Jenkins build jobs are running (using Ansible and my Jenkins role on Ansible Galaxy), they hit an error while configuring Jenkins plugins. The error is something like: