Rules is a new feature that replaces only/except and allow for finer grain
control on the workflow. With rules, we gain finer grain to pipeline and merge
request pipelines.
Declare an docker build-arg [1] and use it
whenever cloning one of our repositories. If the buildarg
is not specified, the variable defaults back to 'master'
and thus the current behavior doesn't change.
From the .gitlab-ci.yml file, when building pass
the GST_UPSTREAM_BRANCH that's defined from the ci_template
as the buildarg so we will be building the corresponding branches
for the docker images.
Close#33
[1] https://docs.docker.com/engine/reference/builder/#arg
Previously we tried using the git commit ref as a UID for the
images. This does not work though cause multiple jobs that rebuild
the image can be triggered and override the same image tag. Instead
use the CI_JOB_ID to provide better semantics wrt naming conflicts.
Additionally add the date as part of the tag to better indicate
the age of the image. Gitlab WEBGUI doens't indicate the age
in a good way nor makes it easy to short the images.
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.
