Add a pre-commit hook that automatically checks if GES children properties
documentation is up to date when GES source files are modified. The hook
runs the document-children-props.py script and warns if the generated
documentation files have changes that need to be committed.
This ensures that children properties documentation stays synchronized
with code changes and prevents outdated documentation from being merged.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5987>
We were building a different image cause we needed to do
a couple things that are not possible yet through
cbuild/ci-templates.
Now that we have FDO_DISTRIBUTION_POST_EXEC we can
do it on the same job and use the same image tag to
extend the image.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9277>
Docker/oci and thus gitlab-runner, default to a root
user inside the namespace, even if its an unprivileged
one.
This can cause issues and let permission bugs sneak in,
as we are functionally root when running the build.
Switch the build jobs to run with our new "containeruser"
so we avoid much of it.
Our user is still in the wheel/sudo group but that's fine
as long we don't elevate the privileges unintentionally.
Noticeably for the time being, we will need to chown the
CI_PROJECT_DIR checkout as the gitlab runner might try
to reuse pre-existing and cached volumes of the project
checkout.
Additionally we need to change the ccache path, so we
will avoid the existing cache owned by "root".
Close https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2433
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8763>
We are currently running pip as root which will cause it
to install into /root/.local cause it wants to do a user install
Set the user-base in the gloabl config, /etc/pip.conf, so pip will
both install there and subsequently look there if we invoke it
from any other user.
This makes pip install ofc require elevated permissions, as it
will be writting into /usr/local from now on
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8763>
Create a file we can check at runtime, and identify if the
environment we run against is one of our CI build images.
Useful mostly for our internal scritps so we can match against
metadata rather than heuristics, ex. if /subprojects exists
Conceptually similar to /.flatpak-info
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8763>
Now that we have the monorepo, we always have a checkout
of gstreamer and we don't need to explicitly clone it again.
cbuild in ci-templates will always clone the repository in
/tmp/clone and we can use that to initialize the cache.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8994>
Devcontainer [1] is a popular container schema that makes
IDEs and tooling aware about the container image you want
to use and develop against.
The most popular implementation of devcontainer are Visual
Studio and VSCode and this allows us to have a out of the
box pre-defined and working build environment that is very
close to the environment CI runs against.
This also allows VSCode on Windows and Mac to setup a
Linux docker container (vm) to develop against if so
desired.
[1] https://containers.dev/
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7816>
We install the rust toolchain, but then we have to manually
source it in CI since the headless containers skip over
the shell profiles that rustup typically uses.
Ideally we'd set these as variables in the main image, but
we don't have access to the buildah instance used in
ci-templates/cbuild.
However adding them to the toolbox image is good enough to
have the toolbox setup work ootb even if it doesn't call the
ci/scripts/source_image_env.sh script like the gitlab-ci jobs
will do.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7816>
Previously the script will give you a command like:
```
toolbox create gst-toolbox ..
```
Which is a bit redundant since we are already creating
toolbox, we don't need to label it as such.
Now instead use gst-$GST_UPSTREAM_BRANCH for the name,
so we will suggest gst-main and gst-1.24 instead
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7816>
Intead of passing around the output of the config generator program,
which consists of paths joined by a separator we can have the generator
simply produce an extra file containing those paths.
This commit only implements the new approach for the core plugins, as
this was needed to avoid spurious meson rebuilds when the pre-commit
hook regenerates the core plugins_cache.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8231>
* Move the exported PATH variables into a script so
we can source it in all the wrapper scripts.
* Add a guard to only copy over the cache when the
SUBPROJECTS_CACHE_DIR variable is set, which only
happens on CI by default
* Make it possible to run the scripts with default
values for some of the variables, like WERROR and MESON_ARGS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7591>
This is mostly done to remove the hardcoded HOME
env var that ci-templates appends to the image. See [1]
[1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2433#note_2243222
But it also allows us to add extra things useful for local
development to it, as long they don't interfere with the
build enviornment.
This also means we can switch the build image to be based
on top of the normal fedora one rather than toolbox,
so it will no longer advertise the toolbox compatible labels
since it was buggy anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7455>
