Automatic test of pip and docker

[ad-daniel]

Description
Tests the latest pip wheel & docker available online.
This PR also addresses missing dependencies for the wheel

[ad-daniel]

@passalis did you by any chance ever encounter this issue when installing from pip?

The conflict is caused by:
    opendr-toolkit 1.0 depends on pkg-resources==0.0.0
    opendr-toolkit 0.9 depends on pkg-resources==0.0.0
    opendr-toolkit 0.1 depends on pkg-resources==0.0.0

As far as I can tell it seems to be a "old" bug where when freezing the requirements, the line pkg-resources==0.0.0 is added to the requirements.txt file, but I personally never encountered issues with it on my local machine. To fix it, it might just be sufficient to crop this line from the requirements when its created, but to be honest I never noticed it was there to begin with. Do you have any clue?

[passalis]

@ad-daniel I am working on this issue. It seems a bit more important than I originally thought. There are some missing files needed for some tests in the wheel, as well as some missed dependencies. Also, there is an issue with some C extensions that need to be compiled for object detection 3D. I will try to fix the wheel generation process (most probably I will also create a separate script in order to isolate this process from the process of building the whole library) and fix the remaining issues. Is it ok to use this PR for the fixes since they are related to pip package?

[passalis]

I think I fixed the issues. I also switched from binary distribution into source distribution, since parts of the object detection 3d needs to be compiled and I didn't managed to do it in a way that would satisfy auditwheel... This would also allow to install the package into any python version (given that dependencies are satisfied), so it also solves this issue. I think this change would be transparent to the pip users, apart from one additional dependency (python3-dev) and a slightly longer installation time (it is still very quick though)

One issue that remains is that object detection 3d seems to fail after the tests have been completed successfully:

----------------------------------------------------------------------
Ran 6 tests in 439.723s

OK
avg forward time per example: 6.750
avg postprocess time per example: 0.000
generate label finished(11418.25/s). start eval:
Loaded Pytorch VFE and MFE sub-model.
Loaded ONNX RPN sub-model.
Loaded Pytorch VFE and MFE sub-model.
Loaded ONNX RPN sub-model.
Saved Pytorch VFE, MFE and RPN sub-models.
Saved Pytorch VFE, MFE and RPN sub-models.
free(): invalid pointer
/home/runner/work/_temp/72ff736c-9900-4f09-8499-4ed1d62014bc.sh: line 12:  4339 Aborted                 (core dumped) python -m unittest discover -s tests/sources/tools/perception/object_detection_3d
Error: Process completed with exit code 134.

It seems that some code runs after the tests have been completed. I have tested using the same package used in CI and I cannot reproduce this locally. @iliiliiliili do you have any ideas on what could cause this?

[ad-daniel]

I can't reproduce it locally either for object detection 3d, but the new wheel works fine otherwise.

Perhaps it's the occasion to move the wheel creation to the CI as well. I believe we can freely push packages to https://test.pypi.org/, with the workflow being triggered by a new tag-creation event on github. I'll look into it today/tomorrow

[ad-daniel]

Thanks for the debugging effort, I think we can disable it for now and perhaps mention it on Monday.
Concerning the workflow itself as a whole it doesn't make much sense to have this test install label that tests the wheel/docker image for the simple reason that although we want to know if they work, I don't see an occasion where we would want to put this label on a PR ourselves, as what is being tested isn't related to a change done in the PR we add the label to. I think the best approach is to have 2 separate workflows:

Test packages:

• automatic nightly test (scheduled run)
• test packages trigger (if needed)
• objective: ensure the current wheels/docker hosted on a third party site run as intended

Test install/pre-release:

• test install label trigger (or test release)
• objective: the purpose is to check if a wheel/docker created from the CURRENT branch/commit works. It's basically a pre-release check. An example of usage of this label could be:

Before we intend to make an official release we would:

1. merge develop into master
2. create a PR that bumps the version file and set test release on this PR. This workflow will:
   • checkout the current branch
   • build wheel and docker image from the current branch
   • upload the wheel/image to a different CI instance (this step is tricky but I know it's doable at least for the wheel)
   • the other CI will download it, install it, run it
   • if all is green, we are ready to publish since we know a build created from the current state of master would work
3. merge
4. create a tag from github, which will trigger the automatic build/publish to dockerhub/pypi

This second workflow can be done in a different PR, I think we should prioritize pushing the updated wheel before that.
I've added docker test as well which seems to work except for mobile manipulation

[ad-daniel]

Looks like that did the trick 😄 the PR is ready for review as far as I'm concerned.

@passalis I don't know what you think and if you agree about the change to the workflow described above

[passalis]

The workflow sounds fine to me! Indeed, using the labels in this way makes sense. Thank you!

[Pavlos-Tosidis]

Seems fine