Jenkins: allow test to specify docker image with default

[lamping7]

This will allow for specialized environments or for testing multiple setup. Use case -- Gazebo 8 for #10780

Additionally I'll push a DO NOT MERGE commit once we have a Gazebo 8 container built for testing.

@TSC21 @mrivi

[TSC21]

Yep this is a good approach!

[lamping7]

@TSC21 I re-pushed the same commit to get a clean test status as Jenkins didn't run on the original commit. I ran it manually in CI and the result was good (except for the expected FW test that failed). Let's let the re-tests here complete. But, it should be good to go.

Note: The attitude test is being kept back (which allowed for the test of this PR, showing it's use case) until MAVROS pushes a release with mavlink/mavros#1161 and we update the container appropriately.

[lamping7]

Attitude test still failed... needs looked at.

[lamping7]

@TSC21 From what I can see PX4 sitl isn't fully launching. The logo never appears and MAVROS never connects. Is there something that makes the two containers incompatible? The build of PX4 sitl and sitl_gazebo is happening in 2019-01-25, while we're trying to run the package built there in 2018-09-11.

[lamping7]

I'm going to keep some notes here in case anything triggers an idea for someone and so I don't forget:

• I grabbed the 2018-09-11 docker image and ran it locally. Inside it, I used wget and pulled the package artifact from Jenkins that was produced with 2019-01-25 here
• I extracted it as Jenkins does, then executed the test, again just as Jenkins does.
• The result was the same as in Jenkins. PX4 seems to get hung up during startup. When I kill the test, or it hits the timeout you see: ERROR [px4] Startup script returned with return value: 2
• Thinking about permission problems with the links created at startup I re-did all this, but used docker run -u 0 -it -e LOCAL_USER_ID=0... After extracting, I chowned the whole dir with 0:0 and tried again.
• Same thing.
• I decided to repeat the test with the same image that created the package, so I pulled the 2019-01-25 image and repeated the first run as described at the top of this post.
• The test ran... Huh?

This is kind of important to figure out what is going on. Not only for the use case here, but for future plans of encouraging users to just pull this package and use it, as in #11124 and #11157 (which doesn't appear to work right now).

[TSC21]

Is there something that makes the two containers incompatible? The build of PX4 sitl and sitl_gazebo is happening in 2019-01-25, while we're trying to run the package built there in 2018-09-11.

From the package built in 01-11 and the ones built more recently there are substantial changes, specially regarding the addition of the lockstep to PX4 SITL and sitl_gazebo. I can't tell if this is causing the problem of PX4 not launching though.

So we don't get stuck with this, let's just put everything at the same stage regarding the container for SITL tests, and when we have the new MAVROS release, we put everything at the same stage.

[lamping7]

What makes this issue interesting is that sitl_gazebo is at that commit specified by this version of PX4. They're in sync, built at the same time then packaged up. The only difference is that we're grabbing this package, built in one container and running it in another. I can open a seperate issue for this.

Either way, I've shown that the PR works and let's you specify a different run container for the test. Should I put everything back to 2018-09-11 and we get this in? I'm fine with that, but until we figure out the problem above it is kind of useless.

[dagar]

Still needed?

[lamping7]

Might not be needed, but we need to figure out the problem I was having

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale.