Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • vidjil vidjil
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,740
    • Issues 1,740
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 105
    • Merge requests 105
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

La mise à jour du service Gitlab est terminée. Merci aux collègues du service de production de la DSI qui ont réalisé cette opération qui outre les aspects évolution du logiciel nous a permis de faire le nécessaire face à des failles de sécurité.
Les principales releases notes concernant cette montée de version sont disponibles ici :
https://about.gitlab.com/releases/2023/01/22/gitlab-15-8-released/
https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/
https://about.gitlab.com/releases/2022/11/22/gitlab-15-6-released/

  • vidjilvidjil
  • vidjilvidjil
  • Issues
  • #1406
Closed
Open
Issue created Nov 29, 2016 by Vidjil Team@vidjilteamMaintainer

Deux fuse servers sur une même machine

Mettons que nous ayions deux instances de Vidjil qui tournent sur une même machie (au hasard une version de prod et une version de test). Chaque instance doit avoir son propre fuse_server. Or, le code du fuse_server précise le port en dur. Du coup impossible d'avoir deux instances parallèles (même problème si le port est occupé). Le serveur pourrait chercher un port libre, l'utiliser et stocker le port utilisé dans un fichier. Ou, plus simple, lire le port à utiliser depuis un fichier de conf.


Est-ce que ce fichier de conf pourrait être simplement modules/defs.py ? Facile à récupérer pour model/task.py, plus délicat pour fuse_server.py, mais pas impossible (defs.py est du python standard, pas web2py)


Dans l'idée oui. Mais je suis toujours un peu gêné par le fait qu'un fichier de conf soit versionné (après il y a des choses qui sont poussées et qui ne devraient pas l'être ;-) ). Ça serait bien que defs.py lise les infos depuis un fichier de conf.


Mmm... il y a bien le module configParser de python qui lit les fichiers à la .ini... mais on ne fait que repousser le problème (au prix d'une complexificaiton) : on devra donner un fichier .ini d'exemple, avec des commentaires pour qu'il soit lisible, et lui devra être versionné.

Donc n'avoir que defs.py me paraît être une bonne solution; et c'est normalement le seul fichier dans lequel on met tout ce qui doit bouger. Après, le fichier versionné peut s'appeler quelque chose comme "defs-example.py", et une copie (ou pas) est effectuée sur le serveur, et on dit dans les instructions d'install comment s'en servir.

http://stackoverflow.com/questions/6009/how-do-you-deal-with-configuration-files-in-source-control

Il y aurait aussi des solutions basées sur git, mais bof... http://stackoverflow.com/a/1396886/4475279


63d6df4c


1612a0be : defs.py.sample


@magiraud

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking