feat: Convert_to_gl_ci flow with Flow Registry

What does this merge request do and why?

This MR converts the existing convert_to_gitlab_ci workflow into a new Flow Registry flow (like we did with issue-to-mr -> duo_developer).

Related issue https://gitlab.com/gitlab-org/gitlab/-/issues/561264

How to set up and validate locally

Example flow: https://smith.langchain.com/public/94fbb0ab-f6f5-4fa4-a78e-041dbfb9efb5/r

1. Checkout ah/convert-to-gl-ci-flow-registry in your DWS and ah/convert-to-gitlab-ci-flow-registry in you local GitLab

2. Enable the FF

   Feature.enable(:convert_to_gl_ci_flow_registry, user)

3. Navigate to a Jenkinsfile in GDK

   # Jenkinsfile
   
   node {
     // Mark the code checkout 'stage'....
     stage 'Stage Checkout'
   
     // Checkout code from repository and update any submodules
     checkout scm
     sh 'git submodule update --init'  
   
     stage 'Stage Build'
   
     //branch name from Jenkins environment variables
     echo "My branch is: ${env.BRANCH_NAME}"
   
     def flavor = flavor(env.BRANCH_NAME)
     echo "Building flavor ${flavor}"
   
     //build your gradle flavor, passes the current build number as a parameter to gradle
     sh "./gradlew clean assemble${flavor}Debug -PBUILD_NUMBER=${env.BUILD_NUMBER}"
   
     stage 'Stage Archive'
     //tell Jenkins to archive the apks
     archiveArtifacts artifacts: 'app/build/outputs/apk/*.apk', fingerprint: true
   
     stage 'Stage Upload To Fabric'
     sh "./gradlew crashlyticsUploadDistribution${flavor}Debug  -PBUILD_NUMBER=${env.BUILD_NUMBER}"
   }
   
   // Pulls the android flavor out of the branch name the branch is prepended with /QA_
   @NonCPS
   def flavor(branchName) {
     def matcher = (env.BRANCH_NAME =~ /QA_([a-z_]+)/)
     assert matcher.matches()
     matcher[0][1]
   }

4. Click on the Convert to GitLab CI/CD button

   

5. Wait for the workflow to finish and confirm that a new MR was created

   

Merge request checklist

• Tests added for new functionality. If not, please raise an issue to follow up.
• Documentation added/updated, if needed.
• If this change requires executor implementation: verified that issues/MRs exist for both Go executor and Node executor or confirmed that changes are backward-compatible and don't break existing executor functionality.

Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/561264