Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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 foudation accounts

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

  2. Contributer License Agreements

    1. LF to provide input
    2. Most likely will use CLA tied to github registred email
    3. Contributers 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 dont 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 Contributer 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


  6. 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

  7. Support.linuxfoundation.org and AsAService LF supported applciations

    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


  • No labels