Learning CoB

# Troubleshooting Guide

This page will contemplate common errors or situations where the cob-cli commands will fail. We will try comprehensively to analyze these situations, and provide solutions or guidelines to help you understand how to fix them.

# Common Error Scenarios

# Case 1: Deploying while tests are running.

In case where a user is testing some changes in machine A (like a groovy script), and some files were temporarily copied into it, if another user tries to perform a cob-cli deploy the command will fail. cob-cli deploy WILL detect current running tests, abort the deploy process if it finds one, and warn the user.

Solution: Wait for the other user to finish testing 😁

# id: 69888 target: Developer

# Case 2: Concurrent tests on the same file(s)

When working together, multiple users may find themselves trying to change and test the same file (at the same time) by mistake. In order for cob-cli to help coordinate work, it will not allow concurrent tests that change the same file(s). This way, it makes sure that no work is improperly overriden or lost.

If user John is performing tests on file A1, and that file has been copied into the server, it will appear in the test.in.execution file, stored in /opt/cob-cli. If another user David then tries to run tests on file A1, cob-cli test will detect that file A1 is undergoing a test, and will ignore David's modifications, until John's test is over - in other words,cob-cli test will ignore and not sync local changes for specific files that are already under testing by another user.

Example 1:

File not synced: there's a conflicting test in progress for this file:
  integrationm/scripts/A1.groovy by John

Solution: Talk to the initial user or wait for him to finish testing 😁

# Case 3: Unclean working tree

In some cases, such as when using cob-cli updateFromServeror cob-cli deploy, cob-cli requires you to have a clean working tree to check if either 1) the server files have not been improperly modified or 2) the user doesn't accidentally push or lose changes. This means the user should have no pending changes, i.e any change/modification in the code should either be commited or stashed via Git:

Example 2:

user@test> cob-cli updateFromServer
Checking conditions to update cob-cli files from <server_name>.cultofbits.com
  ✔ Check connectivity and permissions
  ✔ Check there's no cob-cli test' running
  ✖ Check git status
    → Error: Unclean working tree

 Please clean your working tree before deploy:
 Commit or stash your changes:
	 ? ? integrationm/scripts/test.txt
Error: Unclean working tree

Solution: Either commit your local changes, or temporarily stash them via Git.

# Case 4: Unauthorized / Unexpected / Improper modifications to the Server Files

There is a small possibility that an unwanted / unauthorized / improper modification may have been made to the server files, and is not reflected in the GitLab repository. There are several reasons this could happen:

  1. Someone accessed the machine directly and added/deleted/modified one or more files, for any reason such as an emergency hotfix. Performing this change directly, without properly pushing it to the repository via cob-cli deploy can AND WILL trigger multiple errors.

  2. Improper termination of a cob-cli test that had copied scripts to the server during testing - not terminating this command properly will lead to "leftover" files in the server, which were supposed to be removed when the command is properly terminated.

Almost every cob-cli command (except initand updateFromServer) will have to check if the server has been modified. When these commands do detect a change that does not match the GitLab Repository content, they will abort and show the user the list of modified/unexpected files. Below we show a common error message, which occurs when the current state of the server is different from the last deployed state of the server:

# Solution Guidelines (Case 4)

Depending on the context and origin of the modified/added file(s), your preferred solution may vary, or could even be a mix of the following:

Solution A - Discard modification: Having the right permissions, connect to the machine via SSH (ssh server_name.cultofbits.com). Then go to the directory of the changed file(s) (cd dir), and delete/modify them (rm filename). IMPORTANT: If the cause of the modifications was an improperly terminated cob-cli test, then you must also go to the file /opt/cob-cli/test.in.executionand manually remove the lines that correspond to the files in question.

Solution B - Keep the modification: If you do wish to keep the modification, use cob-cli updateFromServerto update your local working tree with the current server files, and manually delete the new file(s) from the server using Solution A. Then, properly commit the new modification and push it to the repository, or use cob-cli deploy.

Example 3:

user_tester@tester <server_name> % cob-cli test            
Start testing… 
Checking test conditions for <server_name>.cultofbits.com
  ✔ Check connectivity and permissions
  ...
  ✔ git stash pop
  ✖ Warn diferences found...
    →    integrationm/scripts/ola.txt (added)

 Aborted: server was changed since last deploy:
   integrationm/scripts/ola.txt (added)

This error indicates that the current state of the server is different from the last deployed state. If we know that the file and it is not important, we can solve this by running the following commands in the terminal:

  1. ssh server_name.cultofbits.com //log in remotely to the server machine
  2. cd /etc/integrationm/scripts/ //enters the directory of the file
  3. rm ola.txt //remove the file
  4. vi /opt/cob-cli/test.in.execution //open the file, remove the line
  5. integrationm/scripts/ola.txt (added) if the file exists and the line exists in the file too.

Otherwise, if we want to keep the changed file, we can follow what is described in Solution B.

← helper files →