Planet ALUG

Syndicate content
Planet ALUG -
Updated: 40 min 40 sec ago

Jonathan McDowell: Software in the Public Interest contributing members: Check your activity status!

Wed, 13/04/2016 - 13:04

That’s a longer title than I’d like, but I want to try and catch the attention of anyone who might have missed more directed notifications about this. If you’re not an SPI contributing member there’s probably nothing to see here…

Although I decided not to stand for re-election at the Software in the Public Interest (SPI) board elections last July, I haven’t stopped my involvement with the organisation. In particular I’ve spent some time working on an overhaul of the members website and rolling it out. One of the things this has enabled is implementation of 2009-11-04.jmd.1: Contributing membership expiry, by tracking activity in elections and providing an easy way for a member to indicate they consider themselves active even if they haven’t voted.

The plan is that this will run at some point after the completion of every board election. A first pass of cleanups was completed nearly a month ago, contacting all contributing members who’d never been seen to vote and asking them to update their status if they were still active. A second round, of people who didn’t vote in the last board election (in 2014), is currently under way. Affected members will have been emailed directly and there was a mail to spi-announce, but I’m aware people often overlook these things or filter mail off somewhere that doesn’t get read often.

If you are an SPI Contributing member who considers themselves an active member I strongly recommend you login to the SPI Members Website and check the “Last active” date displayed is after 2014-07-14 (i.e. post the start of the last board election). If it’s not, click on the “Update” link beside the date. The updated date will be shown once you’ve done so.

Why does pruning inactive members matter? The 2015 X.Org election results provide at least one indication of why ensuring you have an engaged membership is important - they failed to make a by-laws change that a vast majority of votes were in favour of, due to failing to make quorum. (If you’re an member, go vote!)

Categories: LUG Community Blogs

Chris Lamb: Parsing Jenkins log output to determine job status

Mon, 11/04/2016 - 18:28

I recently made the same mistake a number of times when adding new hosts to my Ansible configuration and decided to ensure it couldn't happen again. The specifics of this particular issue were that whilst I had added the hostname to inventory file, I had neglected to add the host to the relevant group in my playbook:

oldhost newhost [mygroup] oldhost # missing newhost here

ansible-playbook would output no hosts matched but crucially return with an successful exit code. My continuous integration system (Jenkins) would infer that the task was successful and not notify me that anything was wrong:

$ ansible-playbook deploy-mygroup.yml --limit-hosts=newhost <snip> PLAY [deploy] ************************************************* skipping: no hosts matched PLAY RECAP **************************************************** [ERROR]: No plays were matched by any host. $ echo $? 0

This seemed to violate a few principles to me (at the very least due of the "loud" use of ERROR without the corresponding return code) so I filed a pull request against Ansible that added an optional --error-if-no-plays-matched switch:

$ ansible-playbook [..] --error-if-no-plays-matched <snip> [ERROR]: No plays were matched by any host. $ echo $? 1

In the end, upstream decided to pass on it as it could be implemented via a plugin system and desiring an immediate and potentially more-general solution I briefly looked into parsing the ansible-playbook output before moving onto parsing the Jenkins log itself.

This turned out to be straightforward; using the Text-Finder plugin, I configured my Jenkins job to simply error if the log contained the string skipping: no hosts matched:

I am using the Job DSL plugin so that my configuration is backed onto revision control (highly recommended) so I actually used its textFinder publisher rather than the interface above:

publishers { textFinder(/^skipping: no hosts matched$/, '', true, false, false) }

This results in the job "correctly" failing and alerting me:

+ ansible-playbook deploy-mygroup.yml --limit-hosts=newhost <snip> PLAY [deploy] ************************************************* skipping: no hosts matched PLAY RECAP **************************************************** [ERROR]: No plays were matched by any host. Checking console output /var/lib/jenkins/jobs/deploy-mygroup/builds/126/log: skipping: no hosts matched Build step 'Jenkins Text Finder' changed build result to FAILURE Finished: FAILURE
Categories: LUG Community Blogs