cob / cob-cli

cob-cli is a command line utility to help Cult of Bits partners develop with higher speed and reusing common code and best practices.

COB-CLI: customizing CoB servers

cob-cli is a command line utility to help Cult of Bits partners develop with higher speed and reusing common code and best practices.

Installing cob-cli

npm i -g cob-cli

Available commands

There are 4 main commands. The first, init, is to be run once in the beginning of customization of each server. The three other should be used sequentially serveral times during development (1.customize, 2.test, 3.deploy).

• cob-cli init <servername> [-l,--legacy <folder>] [-a,--repoaccount <git acount url>]
• cob-cli customize
• cob-cli test [-d --dashboard <name>, --localOnly, --servername <servername>]
• cob-cli deploy [-f,--force, --servername <servername>]

An aditional command is available to get the repo updated with files from server, which shouldn't be necessary unless changes are made directly to the server and outside of the cob-cli process.

• cob-cli updateFromServer [--servername <servername>]

Finally you can always get this help with:

• cob-cli help [command]

Where aplicable the --servername <servername> option will alow you to run the command agains a diferent server then the standard production one.

---

cob-cli init <servername> [-l,--legacy ] [-a,--repoaccount <git acount url>]

This command has two diferent behaviors, depending on the circumstances:

1. If already exists a repo in https:/gitlab/cob/ (or the specified --repoaccount) for this server just do a git clone of that repo.
2. Otherwise, creates all the infrastucture to suport the server customization. In this last option, if the --legacy is used, in addition to creating the infrastructure it will try to rebuild the server customization history, existing on the legacy repo (old ClientConfs).

By default a new repo will be created in the cob gitlab account, https://gitlab.com/cob. The --repoaccount option allows the use of a different account.

In adition to setting up the local repository cob-cli init also creates the .git/hooks/commit-msg file. This will make set mandatory the use of conventionalcommits for the commit messages to the project.

---

cob-cli customize

This is an interactive command. It allows you to browse the diferent customizations possible and select one. Depending on the choice mode additional details might be requested, and so on. Some examples of customizations:

• General
• Totals dashboard
• Kibana dashboard
• Calculations
• Customize the color of a state field on search result lists
• ...

It also helps you manage the correct git workflow and provide help links to relevante trainning of each customization.

---

cob-cli test [--dashboard , --localOnly, --servername ]

After running the test command you'll enter a livereload state were you can instantly see the effect of the changes being made. To stop this state just press any key.

Many of the changes are serverd locally from the development machine and are not propagated to the production server. These are all files that reside inside the diferent customUI folders.

All other files imply a copy to the server. Each of the files copied to the server has a backup of any pre-existing one. Once the test command ends all copied files are removed and any existing backups are restored.

While in testing you can press o or O to open your default browser with the url for the local tests. You can also use enter to space your logs, if you want.

If you specify a -d <name> the corresponding dashboard will be served from source (instead of built files) and will also provide livereload.

Aditionally you can specify --localOnly if you just want to test frontend configurations without changing other files on server during testing.

---

cob-cli deploy [-f,--force, --servername ]

This last command alows you to deploy your finished developmentto the server, garanting that there are no conflicts with changes made by other. In adition it promotes the management of adequate and updated documentation.

The --force option allows to bypass the conflict test and deploy the local configuration independently of the existing conditions. It should be used with extreme caution and only to resolve problems not possible to resolve in other ways.

Note: This command might not be available to the whole development team and hence some member might just pre-deploy to git hub and it's up to priveledge member of the this to finalize the deploy process after, typically after review.

---

cob-cli's Issues

Better feedback on major version changes in customizations

When upgrading a previously installed customization, cob-cli does not alert to major version changes.

Major versions upgrades are potentially dangerous because they introduce breaking changes that might modify the server's behaviour in ways that are not readily apparent.

The only feedback to the user about what kind of version change was made (patch, minor or major) is given by the diff of the customizations.json file.

I believe there are some options to improve this behaviour:

1. We can give a warning on the output of cob-cli when it detectes a change in the major version
2. We can demand a specific command-line arg to enable that major version upgrades

Any of those should probably include a link to the customizations README file (or a possible VERSIONS one)

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

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 [email protected]: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