## page was renamed from Foundations/QA/QATaggerSetup
= 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.

<<TableOfContents(3)>>

== 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);
  1. Go to the {{{~/qa-tagger/qa}}} folder;
  1. Update the branch on devpad;
  1. Perform a make clean and a make to regenerate the scripts;
  1. 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
}}}