DRAFT FOR USE BY ONAP INFRASTRUCTURE WORKING GROUP

Alexis, Brian Christopfe, Morgan


Background

    1. Long term proposal from the LFN TAC is to replace Gerrit and Jenkins with a more modern tool chain and use an “As A Service” approach rather than dedicted instances.
    2. General plan is to move to a large cloud hosted solution like GitLab/GitLab-CI
    3. We believe reliability will be better
    4. We calculate that costs will be lower
    5. We believe that more modern SCM will reduce the learning curve for new developers

Approach

    1. Prototype with one or two projects to work out the kinks in Frankfurt
    2. Plan to move at the start of G release if approved by TSC in time.
    3. No project moves unless we are ready

FAQ

  1. Common Login

    1.  Common Login will be based on github accounts not Linux foundation accounts

    2. Based on CLA requirements and general biterg.io tracking , contributors should use a corporate email based github account

  2. Contributor License Agreements

    1. EasyCLA supports gerrit and github right now. 
    2. gitlab is on the roadmap but not available yet.
    3. Support ticket SUPPORT-690 created.https://jira.linuxfoundation.org/servicedesk/customer/portal/4/SUPPORT-690
    4. Other notes:
      1. Contributors should use corporate email based github accounts not personal email based github accounts
  3. Biterg.io
    1. Will need to add gitlab repositories to onap.biterg.io
    2. May need to simply have a separate biterg.io setup so we don't double count after initial upload from gerrit to gitlab
    3. biterg probably has a recommended procedure for this type of migration

  4. SCM Reviews

    1.  pull request and branches vs gerrit branches

      1. high level change in flow with git pull vs gerrit

    2. As a Contributor I will use a feature branch instead of working on master and submitting a gerrit review.

      • A developer makes a change in their feature branch and tests it. When they’re happy they push, and make a merge request.
      • The developer assigns the merge request to a reviewer, who looks at it and makes line and design level comments as appropriate. When the reviewer is finished, they assign it back to the author.
      • The author addresses the comments. This stage can go around for a while, but once both are happy, one assigns to a final reviewer who can merge.
      • The final reviewer follows the same process again. The author again addresses any comments, either by changing the code or by responding with their own comments.
      • Once the final reviewer is happy and the build is green, they will merge.

    3. As a PTL I will see pull requests .....

    4. GUI Differences

      1. Cherry Pick

      2. Abandon

      3. Create Branch

      4. Create Tag

      5. Magic Words

  5. CI Jobs

    1. Instead of jjb on jenkins.onap.org my jobs will be .....

    2. Magic Words

    3. Seeing the job queue

    4. Restarting a job

    5. Seeing build errors

    6. Seeing build status

  6. Built-in Docker registry
    1. shall we sync with Nexus/Docker hub assuming that a built-in registry is available
    2. a security portal scanning docker vulnerabilities is also possible
  7. Built-in Artifacts management
  8. Built-in pages (like in github) to host static page (already used to host the pages to monitor the CI chains https://orange-opensource.gitlab.io/lfn/ci_cd/chained-ci/
  9. Enforcement of community by laws and practices
    1. How will we publish release artifacts  (nexus)  and release docker containers (nexus3/dockerhub) ?
      1. Will there be any change ?
    2. INFO.yaml is used to track and automatically populate LDAP with PTL's and Committers , what will be the new process with gitlab as a service ?

  10. Support.linuxfoundation.org and AsAService LF supported applications

    1. How to get help through LF for SCM/CI in As A Service

    2. Escalations

References

  1. https://about.gitlab.com/devops-tools/gerrit-vs-gitlab.html