Try multiple subnet numbers until successfully creating a network. This
way we can run the same ttcn3 testsuite multiple times in parallel
without conflicts (e.g. once against latest, once against nightly). Also
we don't need to make sure each new testsuite has a unique subnet
number anymore.
I've considered also adjusting network_bridge_create, but that gets used
exclusively by osmo-ran/jenkins.sh, a script which we don't actually run
in jenkins. It seems that in this script it makes more sense to not get
a random subnet number.
Related: OS#5802
Change-Id: I57152b08ef0f38e17e7019a8df032189b03f56cf
The functionality is not in -latest yet so running osmo-hnbgw with this
configuration fails which in turn fails the test in jenkins instead of
just marking it unstable.
Change-Id: I4309c323c1d61e8f22dae499c407d57999f6f13a
Same as done in BTS_Tests. This makes sure the files are always properly
updated even if something goes wrong (such as docker kill failing to
stop hnbgw because it exited earlier due to unsupported feature).
Change-Id: Iac3bd9cf3448e18930dcef6c9ae4b6530939ffe6
Other remotes are mirrors of gerrit one, which means there's some delay
between pushing some ref to the gerrit remote and having them available
in the mirrors.
Hence, it becomes annoying while developing and new stuff to test is
pushed. Let's simply use gerrit since it's the master remote.
Change-Id: Ic87c196f8b91a3a3e6ddde2cca36482ce7070df7
Run HNBGW tests a second time with PFCP enabled. Just run all the same
tests again, no matter if they are related to PS RAB Assignment or not,
to also ensure no ill side effects from PFCP configuration.
Related: SYS#5895
Depends: I511e758807e0512c18f3f9e0a8c4699b9a3f5992 (osmo-ttcn3-hacks)
Change-Id: I02b60941343000a4618e95f56326bec170c32bfe