Differences

This shows you the differences between two versions of the page.

--- bb:misc [2019/12/02 14:53] – [Accessing directly some slave.] Jean-Michel Beuken
+++ bb:misc [2024/04/20 10:28] (current) – [Triggering the execution of the automatic tests] Jean-Michel Beuken
@@ Line 7: / Line 7: @@
 There are two ways to trigger the tests on the test farm:
-  *     a merge request of your branch to trunk/develop will trigger nightly (the bunch starts around 10:30pm European time) the launch of automatic tests on all the "nightly" slaves ;
+  *     a merge request of your branch to trunk/develop will trigger nightly (the bunch starts around 10:30pm European time) the launch of automatic tests on all the "nightly" workers ;
   *     a general "on-demand" Web page on bbportal. You can contact Xavier if you think you are sufficiently expert to use it, provided (of course) you need it for your development.
-You will receive by mail the results of the execution of the tests, concerning each nightly slave, one for each slave. Congratulation if your compilation succeeded, all the tests succeeded, etc !
+You will receive by mail the results of the execution of the tests, concerning each nightly worker, one for each worker. Congratulation if your compilation succeeded, all the tests succeeded, etc !
 ===== How to handle failures ? =====
@@ Line 34: / Line 34: @@
-=====  Accessing directly some slave. =====
+=====  Accessing directly some worker. =====
-If you have git branches, you are entitled to have interactive access to each of the slaves. Moreover, you can login as "buildbot" user, and place yourself as if you were the one who just made the run reported in the mail that you received. Hence, you are directly placed in an environment ready to debug.
+If you have git branches, you are entitled to have interactive access to each of the workers. Moreover, you can login as "buildbot" user, and place yourself as if you were the one who just made the run reported in the mail that you received. Hence, you are directly placed in an environment ready to debug.
-  -  Login on a gateway (well, the first time, contact Jean-Michel Beuken, to allow your machine to connect to the private network).\\ **ssh USERNAME@hall.abinit.org**
+  -  Login on a gateway (well, the first time, contact Jean-Michel Beuken, to allow your machine to connect to the private network - the following instruction assumes your public key is ~/.ssh/id_rsa_abinit ) : \\ create a new section in ~/.ssh/config \\ <code>Host abifarm
+   Hostname hall.abinit.org
+   Port XXXX
+   User USERNAME
+   IdentityFile ~/.ssh/id_rsa_abinit</code> and use \\ <code>ssh abifarm</code>
   -  To take the hand over buildbot, execute :\\ **sudo su - buildbot** \\
-  - Now, you need to access other machines of the testfarm, use the supplementary step\\ **ssh <name_of_the_machine>** \\ where <name_of_the_machine> might be abiref, ubu, max2, etc. e.g. **ssh abiref**\\ The first part of the name of the bot is the name_of_the_machine.
+  - Now, you need to access other machines of the testfarm, use the supplementary step\\ **ssh <name_of_the_machine>** \\ where <name_of_the_machine> might be alps, ubu, scope, etc. e.g. **ssh alps**\\ The first part of the name of the bot is the name_of_the_machine.
   -  **cd ABINIT**
-  -  **cd**    to the directory for the particular builder that you want to debug (the machine might support more than one builder) ( ex: cd abiref_gnu_9.2_openmpi )
+  -  **cd**    to the directory for the particular builder that you want to debug (the machine might support more than one builder) ( ex: cd alps_gnu_9.3_openmpi )
   -  **cd**    to the directory for the particular branch that you want to debug (the one bearing your name)  ( ex : cd trunk_develop )
   -  Use the command "module load NAME_OF_BUILDER" to select the compiler that you want to use (type "module avail" to see the list of options). \\ Try to solve your problem ... ! You can modify the files, recompile, etc ...
-  -  The slave can handle usual git commands. So you might make modifications, commit and push to your branch. Of course, after commit and push, it is also advised to test your modifications on your own machine, before using again the test farm, although this is no mandatory.
+  -  The worker can handle usual git commands. So you might make modifications, commit and push to your branch. Note however that by default, buildbot is in a "detached HEAD" state. You can check this by issuing **git branch -a**. You need to checkout your branch, with the command **git checkout <name_of_your_branch>**.
+  - Of course, after commit and push, it is also advised to test your modifications on your own machine, before using again the test farm, although this is no mandatory.