Usar cob-cli em servidores onde o user cob só consegue executar alguns comandos com sudo

[joaoFelix]

Actualmente o problema põe-se na PT, onde o user cob tem privilégio sudo para tudo (pelo menos na máquina de Dev) mas o cob-cli não está preparado para executar comandos com sudo e está a dar erro a criar o repositório porque não consegue criar a directoria /opt/cob-cli/ para escrever no ficheiro /opt/cob-cli/DEPLOYLOG.md:

Creating project server_sigre
  ✔ Check connectivity and permissions
  ✔ mkdir server_sigre
  ✔ cd server_sigre
  ✔ git init
  ✔ Get initial defaults
  ✔ git add .
  ✔ git commit -m ´chore: default configuration´
  ✔ git remote add origin git@gitlab.com:cob/server_sigre.git
  ✔ Get current config
  ✔ Preserve empty directories
  ✔ add .gitignore
  ✔ add .server
  ✔ git add .
  ✔ git commit -m ´chore: Base configuration´
  ✖ Register release
    → mkdir: cannot create directory ‘/opt/cob-cli/’: Permission denied
    git push origin

Possivelmente não se aplica apenas ao cob-cli init, não tenho a certeza.

O que fazer nestes casos?

As soluções que pensei foram:

1. Garantir sempre com os admins dos servidores que o user cob tem permissão de escrita sobre as directorias necessárias
2. Alterar o devops para criar logo as directorias necessárias para conseguirmos executar o cob-cli no servidor e com as permissões correctas para o user cob
3. Ter uma opção no cob-cli para executar os comandos com sudo (tipo cob-cli init sigre -S, onde o -S indica que queremos executar com sudo)

Possivelmente a opção mais razoável será a opção 2 onde, ao fazermos cook da máquina, já garantimos que ficará tudo preparado para que o cob-cli execute sem problemas mas queria a vossa opinião. @adagios @jbarata @mimes70

[mimes70]

Concordo que a opção 2 parece ser a melhor.

[adagios]

A opção 1 é na practica impossível.

A opção 3 é a melhor. Porque funcionaria sempre.

A opção 2 parece-me o segundo melhor, se acharem impracticável alterar a cob-cli. Mas será sempre um jogo do gato e do rato: corremos a cob-cli, não dá, corremos o cook, voltamos à cob-cli. Porque vai-se espalhando ao longo do tempo à medida que cozinhamos as máquinas. E sempre que aparecer uma dir nova na cob-cli, voltamos ao início com as máquinas todas.

[jbarata]

Lidos os argumentos, tb me parece melhor a opção 3 (o q não impede simultaneamente a opção 2 de ter já as dirs preparadas nas novas máquinas) e evita usar depois o sudo nessas. Assim, a mim o melhor parece um mix da 2 com a 3.

[mimes70]

O problema da versão 3 é implica conhecimento e permissões que muitos parceiros não vão ter (pelo menos no início). Um dos objectivos é simplificar trabalhar com cob e assim vamos complicar. Acho que a solução pode passar por ser a cob-cli a criar mas sem requerer que o parceiro explicite a necessidade de sudo. Se for possível então tb acho que deve ser a opção 3.

[joaoFelix]

O problema da versão 3 é implica conhecimento e permissões que muitos parceiros não vão ter (pelo menos no início). Um dos objectivos é simplificar trabalhar com cob e assim vamos complicar.

Os parceiros actuais não precisam desse conhecimento, as máquinas actuais com este problema são da nossa responsabilidade.

Caso haja algum parceiro nestes condições e que queira usar a cob-cli... tem de viver com as consequências das escolhas feitas 😄

Acho que a solução pode passar por ser a cob-cli a criar mas sem requerer que o parceiro explicite a necessidade de sudo.

Não percebi o que isto quer dizer... tentar sem sudo e, caso falhe, tentar com sudo?

[adagios]

Não percebi o que isto quer dizer... tentar sem sudo e, caso falhe, tentar com sudo?

Parecer-me-ia que sim.

[mimes70]

Não percebi o que isto quer dizer... tentar sem sudo e, caso falhe, tentar com sudo?

Parecer-me-ia que sim.

Sim, isso.