There is no point in doing a different docker image for each build we
are going to do inside an Ubuntu distro. We can later use the same image
for native ubuntu builds, or other cross builds (e.g. android API 21,
etc).
It was installed in '/' which doesn't feel right. Installing it in /root
is also not correct because we want to run the build as user instead of
root in the future and cleanup.sh removes everything in /root. /opt
seems the best place because that's also the default location when
installing Android Studio.
While they are very useful, each time we create a branch,
gitlab tries to build all the images which is very resource
intesinve. Thus make all the local images and everything that
depends upon them a manual job and only trigger them before
merging an MR.
Add a fedora job that runs the 'check' tests with
gst-validate-launcher. Its fairly well abstracted so the same
template can be used to add the rest of the test-suites fairly
soon.
The tags are only used to version the images that are meant
to be used in the gitlab/ci_template.yml file. Thus tags are
not needed when you hack on a patch from a forked repository.
Lets just keep a :latest tag.
Idea is that in order to not consume many resources for broken
builds, we will have a basic stage where just one simple set of
build and test jobs is run. If that passes we will continue with
the rest of the Pipeline suite.
If we are in a fork of the project, we would like to be able
to overwrite the `:latest` tag if the registry from any branch
so we won't have to manually overwrite the image tag in the
build/test jobs in the .gitlab-ci.yml file
Make it so when we build a new image in `gst-ci` it gets
picked up automatically by the job in this repo. For the template
itself we want the images to me be versioned and reproducible.
Right now we only have one test against build_manifest.py, it
is not needed to run this test if that code haven't changed.
It's really easy to add more file or set a wild card in the
future.
In order to be able to query the Gitlab Group API we need to be
authenticated. CI_JOB_TOKEN for public jobs has a non-meaningfull
value which does not actually authenticate the Runner to the
intance.
