Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gstreamer-project gstreamer-project
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 10
    • Issues 10
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 2
    • Merge requests 2
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamer
  • gstreamer-projectgstreamer-project
  • Issues
  • #6

Closed
Open
Created Aug 03, 2018 by Thibault Saunier@thiblahute🌵Maintainer0 of 5 tasks completed0/5 tasks

Migrate our jenkins based CI to gitlab-ci

This is just an issue to track our progress and goals on moving from jenkins to gitlab-ci.

Goals:

  • Have at least the exact same CI level as what we have on Jenkins:
    • Run on last stable release branch
    • Build on windows/mac OS/linux (ubuntu+fedora)/IOS/android
  • Run all CI on each and every MR before merging
    • What "level" of CI do we want on MRs? (ie. should we run validate tests? What cerbero configs should we test, etc...)
    • How do we run CI on MR with interdependencies (eg. a MR in -bad requires a commit from -base)? We need to make sure that the end result is properly reported on MRs for each component.
  • Run CI on forks so that developer know that it passes before proposing a MR (same issue about interdependencies between GStreamer components)
  • Allow any developer to update the various component of our CI
  • Properly report test results in a way that allows us to follow results history

(Those are the ones I have on the top of my head and it should be updated/better defined).

As discussed several times at hackfest, we should have Docker images to run our CI against, Edward started that, and I buily a little .gitlab-ci.yml file to get those automatically updated with gitlab-ci: https://gitlab.freedesktop.org/thiblahute/gst-ci/pipelines. This might be a good starting point to build upon for linux at least.

Afaik there is no Mac or Windows gitlab-runner on gitlab.fdo yet, that should be added.

Also I started a little .gitlab-ci.yml for gst-build: https://gitlab.freedesktop.org/thiblahute/gst-build/ which has 3 stages, one to build a "manifest", one that builds (currently only in the arch container) and a last one that runs check+validate tests and exports the results using allure. This is me playing with the idea, but I have idea about how to fulfill previously described goals based on what I have and we should discuss it I think.

Edited Aug 03, 2018 by Thibault Saunier
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking