• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

QA-tagger setup

This page describes how to deploy new code to qa-tagger production instance, how and which cronjobs are configured, how to deploy and to QA new deployments.

QA-tagger deployment

To deploy a new version of qa-tagger on devpad, you have to follow three steps:

1. Make sure the desired revision is current on the qa-tagger devel branch.
2. QA!
3. Apply changes to production.

QAing the tagger

You need to update the "qa" branch on devpad to do that. Steps to go:

1. Go to devpad, and become the lpqateam user (you might need to file an RT requesting access to the lpqateam group);

2. Go to the ~/qa-tagger/qa folder;

3. Update the branch on devpad;
4. Perform a make clean and a make to regenerate the scripts;
5. Profit!

  $ cd ~/qa-tagger/qa
  $ bzr up
  $ make clean && make

Now you should edit ~lpqateam's crontab commenting the "current" line and uncommenting the "qa" one. The invoked script is tag-nator-o-matic.sh, which runs ./bin/tag-bugs to each project and branch.

Note: QA-tagger generates the reports and place them always in the same folders, unless you tell it not to. So, while doing QA, users will see the reports generated by the code being QAed. The thing about having "qa" and "current" is that it's easy to switch back to a working version. If QA fails miserably, just change the cron entry back to "current" version, and you're safe.

Note 2: QA-tagger processes the revisions sequentially. So, if you notice a breakage and want QA-tagger to reprocess revisions, go to the proper last-revno-<project>-<branch> file and change it to the last successfully processed revision. This way, QA-tagger will start processing from this one in the next run.

Deploying to production

Once you have QAed the script enough, and it's proven working well, do the same updating process in the "current" folder:

  $ cd ~/qa-tagger/current
  $ bzr up
  $ make clean && make

And you're done. Latest version running on production is now the QAed one.

Runtime files

To run properly, qa-tagger uses a set of files named last-revno-<project>-<branch>. They store the last processed revision for each project and branch. The revision files are in ~/qa-tagger/revisions, and each running instance has links pointing to those files. Usually you don't have to do anything about it, but if the links aren't there, just create them.

Same happens to the qa-tagger logs. Logs are in the ~/public_html/qa_reports/logs folder. There should be a link in the current branch; if not, just create it.

This linking approach was created to avoid having to copy runtime files every time a new branch was deployed. This way you only need to worry about updating the branch, and nothing else.

Cronjobs

The only crontab job running is the one that triggers the script. There are two entries in the ~lpqateam crontab, one for the "qa" instance and another for a "current" instance. Only thing needed is to switch between them.

# qa bug tagging tool 
*/10 * * * * cd $HOME/qa-tagger/current && ./tag-nator-o-matic.sh
#*/10 * * * * cd $HOME/qa-tagger/qa && ./tag-nator-o-matic.sh