Admin
Last updated
Last updated
The installation process on the occasion of a fresh system is several steps which are listed below, in the case of steps that were previously performed on a particular computer, you can skip individual steps.
The first step would be to install a package manager if you still don't have one, for Windows this would be choco, and for macOS homebrew.
To do this you need to paste the following command into Powershell or Terminal respectively.
If you have encountered any problems, it is recommended to check the program's documentation, which for Windows can be found and for macOS .
If you use Windows you will also need to install git, which you can do by running.
The next step will be to install Chrome and Chromedriver.
In the next step, we will install python.
If you encounter a problem with pip installation, you can use instead of command above:
In this step, we will take care of the installation of Ruby.
The final step will be to install imagemagic.
In addition, on Windows, you need to download msys2 and you can do this with the following command.
to be released...
On macOS, when you launch the application, the first screen you see will inform you of the current status of your granted permissions.
You need to click the buttons one by one which will open the appropriate tab in the settings and grant all the necessary access to the application.
After doing this, the window will close and you can proceed to the next step.
Automatic updates work in a very simple way in which you won't even notice them. The important thing is that you don't have to worry about the update interrupting your work as this process doesn't start while the bot is running. After the update is finished the bot will turn itself on and connect to the portal so that it can continue working.
The only thing you need to check is whether you need to create an exception in the firewall to allow the bot to update itself. A list of hosts that the runner can reach can be found at Firewall exceptions.
The following is a description of the path of how a runner that is ready to work behaves.
We check the server to see if there is a new job for us (every 5 seconds).
There is an empty answer - there is nothing to do, and we return to point 1.
When we have something to do we execute a job.
The result of the job is returned to the server.
We return to point 1.
First, Runner creates a folder for himself with Job, at the following address: ~/.anyrobot/{job_id}
There you will find two folders and such files in such a structure:
input - input files directory.
script - the content of the downloaded task.
payload.json - that is the entire response from the server, example below.
output - output files directory
console.txt - what the console showed - with timestamps, logs etc.
result.txt - What the script showed on the console itself.
Example payload.json response:
Script used as an example:
Note that the working directory is set to the job directory, not the input directory. This may affect the paths of loaded files like "payload.json" → "input/payload.json".
We already have everything downloaded, in the right folder, so the application executes this file (in case you need to give, for example, chmod +x on it, using the built-in console. The application is agnostic to the programming language used, so it is very important that the first line of the file is a shebang:
Thanks to this Runner knows how to run such a file. The command contained in the shebang (ruby, python, node, etc...) can be changed at will and is passed as a script call command. For known types, additional environment configurations are put in place for the Activity Monitor to work seamlessly.
As with a regular job, its folder is created.
Then the Runner, based on the DownloadUrl from the Task from Job, checks if it has such a repository cloned on disk, and if it has anyrobot.yml.
If there is not then:
Clones and changes the branch to a value with BranchName from Task from Job.
Checks if the project anyrobot.yml file exists.
Parses the anyrobot.yml.
Executes install_command from anyrobot.yml.
Executes after_install from anyrobot.yml.
If something goes wrong it aborts the operation.
It checks if there is a new version using git branch and determines possibly if it is detached, then git rev-parse HEAD and git ls-remote -q origin refs/heads?{branch}.
If there is a new version:
Executes before_update from anyrobot.yml.
Saves information about the last commit.
Updates to a newer version: git reset --hard, then git switch {branchName} and git pull.
Checks for anyrobot.yml and parses it.
Executes after_update from anyrobot.yml.
If the update procedure did not go as planned and something went wrong it performs a git reset --hard and checkout commit, which he saved for himself in point 2.
Once everything is ok the following are launched in sequence:
Executes before_runner from anyrobot.yml.
Executes after_runner from anyrobot.yml.
If nothing threw an exception or no bad execution code appeared in the terminal Job returns success. In any other case, if something goes wrong during any step a fail is returned (and a report to sentry).
There are two possibilities, the executed Job can be successful or failed, and accordingly, then different responses are sent.
Let's assume that the executed script will display something like this:
Here there is no special tag, so the return to the server is quite simple afterwards:
Let's assume that the executed script will display something like this:
Thus, to the server goes the information about the failure:
The script is responsible for preparing the files result.json and attachments.json in the output directory. If either file is created its contents will be attached to the corresponding key in the uploaded result: "result" for result.json and "attachments" for attachments.json. If no file is created, the key will not be added.
Here is the list of hosts used by the applications:
your portal address
If you are using Windows before proceeding further you must first download .NET Runtime 5.X from .
For project-based Jobs, the principle is very similar to file-based. The biggest difference is the appearance of the anyrobot.yml file which is presented in more detail .
Executes runner_command from anyrobot.yml with passed parameters.
For more detailed information about this step, see above.
More is explained in the chapter and .
sentry address - check out sentry docs
