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>
In the CI we don't have x11 or wayland compositor running,
so the va plugins don't initialize and the tests will keep
running against software encoders/decoders.
However when running locally or inside toolbox, this will
allow va plugins to initialize and be tested.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7762>
