Deploy image build

Last jobs get stuck pushing the image. Trying to use the JFrog CLI interface instead of a raw docker push using a simpler test repository for faster iteration:

https://git.code.tecnalia.com/tecnalia_robotics/sandbox/simple-deploy-test/-/jobs/26395

Summary of today's shenanigans:

Miserably failed to make JFrog CLI succeed using the simple-deploy-test repo
Using plain docker push is the only succeeded job in simple-deploy-test
See jobs

After multiple last minute trial and error repetitions with Aitzol, we have found a combination of commands that allow pushing a docker image using JFrog CLI (at least from local host).

Started two more jobs in the versatile_test_application repository:

Using plain docker push: https://git.code.tecnalia.com/tecnalia_robotics/versatile/versatile_test_application/-/jobs/26503
Using JFrog CLI to push: https://git.code.tecnalia.com/tecnalia_robotics/versatile/versatile_test_application/-/jobs/26512

added 20 commits

a9827b48...57c08712 - 6 commits from branch master
cf3b0344 - Prepare default industrial_ci job for commit/tag variation by extension
dae2df37 - Supress default industrial_ci job for tags
43173a04 - Add scripts/Dockerfile required for deployment script
f1421673 - Add initial deployment steps
3bbfeefa - Commit industrial_ci image
af52ce39 - Do not attempt to remove bind-mounted directories from container
a17151ae - Remove left over empty directories from bind-mounted volumes
f503514f - Make deployment image entrypoint script executable
2eb2bac2 - Make deployment image entrypoint script executable after wget
37a72dd8 - Remove logs folder from catkin_ws before commiting image
5ebf26b4 - Deploy application image to internal registry
b45efde6 - Use fully qualified name to tag image, not just for pushing
87665b50 - Build and push deploy image in 'script' instead of 'after_script'
8228b2a3 - Use new naming scheme for deployment images

Compare with previous version

Rebased on top of master, to include changes in docker image naming convention, and changed the naming of the deployment images built.

Apparently the docker push timeouts were caused by using an access token to authenticate against the artifactory server. A new user has been created to perform this authentication as a proper user and now the push seems to succeed.

I launched one final job for testing using the default template: https://git.code.tecnalia.com/tecnalia_robotics/versatile/versatile_test_application/-/jobs/27034

I believe this is ready for review/comments, @jon.azpiazu.

assigned to @jon.azpiazu

unmarked as a Work In Progress

resolved all discussions

Which launchfile can I use to test it? This one https://git.code.tecnalia.com/tecnalia_robotics/versatile/versatile_test_application/blob/kinetic-devel/versatile_test_application/launch/flexbotics_framework.launch ?

I believe you should currently run https://git.code.tecnalia.com/tecnalia_robotics/versatile/versatile_test_application/blob/kinetic-devel/versatile_robots_lwr/versatile_robots_lwr_launch/launch/versatile_robots_lwr.launch first, to start the robot in simulation, and then the flexbotics_framework.launch you point to.

However, I also believe from some previous tests, that it will not work because some package has missing install rules. I will soon start to test this as well and try to fix the issues in the related packages.

Alternatively, you can try the tecnalia-robotics-docker.artifact.tecnalia.com/sherlock_robot:test-0.0.0 image.

You can run that with:

xhost +local:root
docker run -v /tmp/.X11-unix:/tmp/.X11-unix \
           --env=DISPLAY \
           --network=host \
           tecnalia-robotics-docker.artifact.tecnalia.com/sherlock_robot:test-0.0.0 \
           roslaunch sherlock_robot_sim sherlock_robot_sim.launch

If you know your way around the ManipulatorCommander, you can also launch in separate containers (using exec as an exercise to the reader ):

docker run --network=host \
           tecnalia-robotics-docker.artifact.tecnalia.com/sherlock_robot:test-0.0.0 \
           roslaunch sherlock_robot_manipulator_interface manipulator_controller.launch

and then:

docker run --network=host -it \
           tecnalia-robotics-docker.artifact.tecnalia.com/sherlock_robot:test-0.0.0 \
           python

and inside the Python interpreter, for instance:

from manipulator_commander import ManipulatorCommander
mc=ManipulatorCommander()
# ...
mc.move_joint('left_arm',[1,1,1,1,1,1,1])

Oops, the last test job I launched wasn't right. It should've pointed to the template in a different branch.

See https://git.code.tecnalia.com/tecnalia_robotics/versatile/versatile_test_application/-/jobs/27098

I am happy to merge as it is. Just an additional suggestion: define a roslaunch entry point so that when docker run is used, the relevant entry point launchfile is launched. That way a deploy docker image is completely autocontained.

I think we already discussed this and you did not like the idea, but I cannot remember why.

I'm not against that.

What I may have pointed out is that some applications may require (or benefit from) launching multiple commands (e.g. first launch the robot drivers and separately launch the application, so that restarting the latter doesn't involve restarting the former). I even started to detail the text in the design doc related to the required structure for an application package (not yet pushed).

My proposal is to merge this like it is right now, since we currently don't have any firm specification and each application may use different entry points. Then we can later modify to make use of a standard entry point naming/structure.

merged

mentioned in commit 61c8b9b9

mentioned in commit d2abcf80

Deploy image build

Merge request reports

Activity