Python environment set up via Jenkins?
- Thread starter jerome
- Start date
Hi Jérome and thanks for you query!
In general, one creates a "technical user" (for example named "JenkinsUser") who has "extended rights". For example, what we absolutely want to avoid "in production" (ie for an Anatella job that runs in Jenkins), is that the job stops because the job involved a "too big" data extraction out of the database. As a result, we will give greater rights to the technical user, to prevent a job from being advertised.
When you put a graph "in production" in Jenkins, the graph will stop running under your own name: it will now run under the name "JenkinsUser" (typically). We must therefore ensure the following elements (it is the same list as below):
1. "shared drives" are accessible to the user "JenkinsUser"
2. ODBC-DSNs are accessible to the user "JenkinsUser" (this is not necessary if ODBC type 2 link has been used instead of ODBC type 1 link: see section 5.1.6.2. more info about this).
3. the locations of the R engine and the python engine are specified.
If we do not specify anything, then Anatella is looking for ...
* ... the R engine in the "default" directory named "<timi_install_dir> / r" (typically it will be "c: \ soft \ TIMiPortable \ R").
* ... the Python engine in the "default" directory named "<timi_install_dir> / python" (typically it will be "c: \ soft \ TIMiPortable \ python").
We can still "manually" change, for each box R or Python, the location of the R / Python engine used (it also allows to mix in the same graph Anatella several different versions of the engine R / Python):
View attachment 1
4. the serial number is: either "system-wide", or entered for the user "JenkinsUser".
Even if all jobs run under the same technical user named "JenkinsUser", that does not mean that we can do anything anyway: Jenkins allows to define different "profiles" of users (which are managed by Jenkins and not by the OS). Some "Jenkins profiles" can just check jobs and not add new jobs, etc.
In general, one creates a "technical user" (for example named "JenkinsUser") who has "extended rights". For example, what we absolutely want to avoid "in production" (ie for an Anatella job that runs in Jenkins), is that the job stops because the job involved a "too big" data extraction out of the database. As a result, we will give greater rights to the technical user, to prevent a job from being advertised.
When you put a graph "in production" in Jenkins, the graph will stop running under your own name: it will now run under the name "JenkinsUser" (typically). We must therefore ensure the following elements (it is the same list as below):
1. "shared drives" are accessible to the user "JenkinsUser"
2. ODBC-DSNs are accessible to the user "JenkinsUser" (this is not necessary if ODBC type 2 link has been used instead of ODBC type 1 link: see section 5.1.6.2. more info about this).
3. the locations of the R engine and the python engine are specified.
If we do not specify anything, then Anatella is looking for ...
* ... the R engine in the "default" directory named "<timi_install_dir> / r" (typically it will be "c: \ soft \ TIMiPortable \ R").
* ... the Python engine in the "default" directory named "<timi_install_dir> / python" (typically it will be "c: \ soft \ TIMiPortable \ python").
We can still "manually" change, for each box R or Python, the location of the R / Python engine used (it also allows to mix in the same graph Anatella several different versions of the engine R / Python):
View attachment 1
4. the serial number is: either "system-wide", or entered for the user "JenkinsUser".
Even if all jobs run under the same technical user named "JenkinsUser", that does not mean that we can do anything anyway: Jenkins allows to define different "profiles" of users (which are managed by Jenkins and not by the OS). Some "Jenkins profiles" can just check jobs and not add new jobs, etc.
