Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
D
dbus
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 242
    • Issues 242
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 31
    • Merge Requests 31
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • dbus
  • dbus
  • Issues
  • #303

Closed
Open
Opened Jun 02, 2020 by Ralf Habacker@rhabackerMaintainer0 of 1 task completed0/1 task

Follow-up from "cmake: Fix installed files"

The following discussion from !155 (merged) should be addressed:

  • @smcv started a discussion:

    This is a nice idea, and I appreciate the effort to get this tested, but I don't think it really scales: each build takes a significant time, and adding two extra builds per feature could quickly become extremely time-consuming. If a Gitlab-CI build ends up doing multiple variant builds one after the other in a shell script loop, Gitlab can't parallelize them, so we'd end up waiting for a long time for success/failure feedback from the CMake build.

    Also, just checking that they compile without also running their tests doesn't seem great, and this feature seems confusingly similar to the ci_variant that we already have for Autotools.

    If we want to test additional configurations under CMake, the way to do that is to add more ci_variant builds to .gitlab-ci.yml, and include those configurations in them (they should probably be off-by-default to avoid using excessive CI resources, and we can trigger them manually when needed). For example, with Autotools, the production (default), debug, reduced and legacy variants each use different options. We don't have individual variants for each feature, because it doesn't scale - we bundle a lot of optional features being enabled into debug, and we bundle a lot of optional features being disabled into reduced.

    At the moment the CMake part of tools/ci-build.sh doesn't support variants at all. If you want to add something like

        (cmake|cmake-dist)
            case "$ci_variant" in
                (reduced)
                    set -- "$@" -D ENABLE_SYSTEMD=OFF
                    ... maybe more options here later ...
                    ;;
            esac
    
            case "$ci_host" in
                (*-w64-mingw32)
                    ... back to the current code ...

    mirroring the way it's done for Autotools, then that would be fine.

    The simple way to resolve this would be to drop this commit, and consider adding ci_variant as a separate MR.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: dbus/dbus#303