See we if can and/or should transfer the templates into GitLab CI/CD components

Created on 3 April 2024, about 1 year ago

Problem/Motivation

https://docs.gitlab.com/ee/ci/components/index.html
Doing this would allow sharing the templates easier across other GitLab instances.

Remaining tasks

- Investigate what needs to happen
- Investigate impact on current set up and integration
- Decide if we are going to do this or not

Feature request
Status

Active

Component

gitlab-ci

Created by

🇪🇸Spain fjgarlin

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @fjgarlin
  • 🇺🇸United States cmlara

    Components is still a BETA feature, would suggest postponing until stable release.

  • Status changed to Postponed 11 months ago
  • 🇪🇸Spain fjgarlin

    Very good point.

  • Status changed to Active 10 months ago
  • 🇩🇪Germany chr.fritsch 🇩🇪🇪🇺🌍

    It's not beta anymore

  • 🇪🇸Spain fjgarlin

    There are some issues marked with 2.x. If this were to happen, doing it via components would be the desired approach.

  • 🇺🇸United States cmlara

    If you want a reference point I have pulled some of the gitlab_templates out into components though they have been modified to better align to my personal build style.

    https://www.drupal.org/project/quasar/ecosystem

    Project is slightly on hold as I’ve decided the DrupalCi Image and its build process doesn’t align to my design needs and I need to create a new custom image (along with the associated build infrastructure ).

    I do have a mostly built phpunit job I haven’t uploaded that’s designed so in theroy you could run the build stage and phpunit stage at once, and customize each job run. Environment variables became a bit key in the design to allow creating base jobs and inheritance.

    My comment about components:
    While it can all be done in this project I would suggest individual projects for each component (this lets you version them separately)
    Only move to components if your willing to adhere to a strict versioning scheme, this is easier now that gitlab has a well defined “inputs”
    System

  • 🇪🇸Spain fjgarlin

    Thanks for sharing the work and your experience with this so far.

  • 🇺🇸United States alexdmccabe Orlando, FL, US / Seminole lands

    I'd like to add that having working with CI/CD Components at my job they're so much better than the older template styles. The ~latest tag alone makes it worth it (it uses latest tag instead of having to use a branch). Having specific inputs and validation of those inputs (via spec:input:options, basically an enum) is also really nice to have.

    I've got a pretty good amount of experience with Components now (a little more than a dozen separate projects), so if there's anything I can to do help with moving this forward, please let me know!

  • 🇪🇸Spain fjgarlin

    If you could help with this that'd be SO amazing! I've even seen some example where both the components and the "old" format can co-exist (https://to-be-continuous.gitlab.io/doc/ref/php/). If we could achieve that, we wouldn't need to wait for a 2.x effort and this could be started.

    If you are willing to help, I'm more than happy to provide background, reviews, etc as you might need them. We could start with the smallest jobs and then start moving up to the more complex ones, and if needed, we could create separate issues to tackle them individually.

    I have not done any component yet as I'm working actively on other projects, but I'd love to see this move forward and I'm sure that once we have one or two, rolling more should be easier.

Production build 0.71.5 2024