vduseev / fate Goto Github PK

There are global variables in main.sh that need a comment to each of them.

There is a way to invoke nc with suc parameters that
syntax completion will be available in IPDB.

SAVED_STTY=`stty -g`; stty -icanon -opost -echo -echoe -echok -echoctl
-echoke; nc 127.0.0.1 4444; stty $SAVED_STTY

Currently stdout is not retrieved from finished container in case
OUTPUT_PATH is used for algorithm results.

It should pulled out in that case as well and reported as additional
logs from container.

Analyzer receives -1 as an input and considers the whole thing to be a shit show.
That's because when using printf I ignored the value argument and put the value directly into the format string.

The resolution: add '%s\n' string before the actual value.

Function should periodically check if any containers are still running
and return when all of them are finished.

It should also forcibly stop any container that exceeds its running time
limits despite being specifically told via docker flag opetion to run
no more that preset amount of time.

Just an idea. Not sure if I'll go with it:

1. What if we spawn N virtuals each with a docker container for each test case?
2. What if we spawn 1 virual with as many CPU cores and mem as required for all our test cases?
3. What if we try to balance between parallel and consequiential execution?
4. Where are we going to store the EC2 image?

Try to launch in ECS docker service. A quick highly limited demo will suffice.

One algorithm outputed -1 as a result which caused
printf to think it's one of its options.

Adding an explicit format string to printf '%s' solved the issue.

Each bash function written in any module must verify its input arguments.
At the very least that they are not empty.

HackerRank has for some God's forsaken reason decided to use an environment variable to store the path to the output file and instead of writing to the stdout write to the file.

It could be justified by the fact that not all users are able to print to stderr and their debug printing to stdout messes up their test runs. Hence, HackerRank changes the system. Well, if that's the case, then a nice written article about the means of using stderr for debugging in any language present on HackerRank could suffice.

Anyway, we need to support this mess now.

Currently a wait of 3 sec is implemented before connecting to debugger
via nc.

This has to be replaced with a proper check via lsof, netstat, or nmap inside
a container before trying to invoke nc.

Something in the lines of

while true; do
  local result=$(docker exec $cid lsof -i :4444)
  if result not empty; then
    break
  fi
  if we are in the loop for more than 10 sec; then
    break
    exit
  fi
done

[Sat Jan 11 20:50:45 MSK 2020] [DEBUG]   Collecting results from all containers...
Error: No such container:path: 9fafe7c79327ab319b85d231d29ea98b86e664efad3c3a78b9b411ddbb47cbd7:/tmp/result.txt

In this case the algorithm failed to write down the file due to a Runtime error in the algorithm.

This shouldn not be thrown out as a result of error from docker cp. Instead this error must be caught and
reported together with other errors.

Currently logs are collected after the docker container has finished
executing in docker module.

I want docker module to return immidiately and instead expose a
function that retrieves the logs based on the CID returned from
initial execute_in_docker_container function invokation.

Replace direct argument passing by value and also returning of the
function values via printf with namerefs usage: local -n var

When running without debug fate reports that the port for debug is already allocated.

This happens because fate launches all the test pairs simultaneously and in parallel in docker containers.
Each one of the launched pairs has same host port mapped to the debugger. Which can't be done.

Actually, same thing will happen when we launch with --debug flag. Because as soon as we are finished
with the first container and its test pair we switch to the next one. And the next one will have a conflict,
because something has already mapped itself to port 4576.

By the way, what if user has something running on that port? Wouldn't it be better to add some heuristics
and radomizations to dance around such issues?

Be able to run a multitude of docker containers in parallel.

1. For every test case
2. Start a docker container
3. Either of two is easier:
   1. Wait for all containers to finish then read their logs
   2. For every container that has finished read its logs and report them imidiately via diff (preferred)

Fate reported exact same outputs between the algorithm and the output file as wrong.

Algorithm from my hackerrank-solutions repo: cats-and-a-mouse

Same 2 lines for the output at both ends, however, error is reported.

Turns out tuning out diff to strip trailing cr might solve the problem.

Detect which language spec is used.

Set up basic PyPI package structure.

The idea is like this:

1. If language is Python3
2. For each discovered test case
3. Start a docker container with python debugger
4. Attach to debugger in that container
5. Debug the code in the container using local machine
6. Be able to see the output right away if it's printed
7. If halted of finished then exit as normal

Currently only one pair of files representing single test case is supported
by being supplied via -i and -o arguments.

As per requirements in README multiple pairs must be supported via
autodiscovery of test case files.

In this feature only consequential execution of all test pairs must be
implemented. This is not the cloud-like-running-all-test-cases-simultaneously
case.

Remove any created and stopped containers. Use --force and also delete any associated volumes via --volumes flag.