Details

    • Type: Sub Task Sub Task
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-4929Deploy KRAD poc to test environment
      KULRICE-14216Analysis - Design a continuous deployment pipeline
      KULRICE-12820Transition 2.5 deploy CI jobs
      KULRICE-1991Fix unit tests that are broken in CI after various merges
      KULRICE-13759Fail CI AFT job if deploy target it depends upon fails, experienced with http://ci.rice.kuali.org/job/rice-2.5-test-functional-env14-jenkins-krad-sampleapp/93/
      KULRICE-13738Update AFT CI jobs that deploy to do test-compile before deploy and fail using extEmail (like test-unit jobs)
      KULRICE-4201Create a POC using JAXB
      KULRICE-14231Git process for Continuous Deployment
      KULRICE-13293Prepare CI for 2.5 Release
      KULRICE-5665Implement the ability to run rice sample app as a seperate application integrated with the Rice Standalone Server, put process in place to automatically deploy to a test environment using CI
    • Sprint:
      Rice Sprint 2015-04-1, Rice Sprint 2015-04-15
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      Set up a proof-of-concept environment and test CI's ability and reliability to running tests against a dev branch and automatically merging into master if tests pass.

      See KULRICE-14231 for process design.

      Scenario success:
      rice-2.6-test-unit, rice-2.6-test-integration-mysql, rice-2.6-test-integration-oracle, rice-2.6-test-functional-env2 -jenkins-rice-sampleapp, and rice-2.6-test-functional-env4-krad-sampleapp are passing. Expected result: automatically merge into master.

      Scenario success variation:
      rice-2.6-test-functional-env2 -jenkins-rice-sampleapp or rice-2.6-test-functional-env4-krad-sampleapp is failing but their associated regression test (rice-2.6-test-regression-env2-jenkins-rice-sampleapp or rice-2.6-test-regression-env4-jenkins-krad-sampleapp) passes. Expected result: automatically merge into master.

      Scenario failure:
      rice-2.6-test-unit, rice-2.6-test-integration-mysql, rice-2.6-test-integration-oracle, rice-2.6-test-functional-env2 -jenkins-rice-sampleapp (and regression), or rice-2.6-test-functional-env4-krad-sampleapp (and regression) failed. Expected result: Email notification to rice team (no merger).

      Ensure:

      • merger only merges tested code, no subsequently committed/merged code changes.

      Variation:

      • Can testing and merging be done against the pull request itself so a pull request that failed doesn't block other pull requests?

        Activity

        Hide
        Jeff Ruch added a comment -

        I think some of the initial assumptions are no longer valid. The currently agreed upon process is:

        1. developer creates feature branch (i.e. KULRICE-12345)
        2. developer completes development and local unit testing
        3. developer creates pull request to Master or rice-xx branch
        4. pull request triggers multiple Jenkins jobs to be kicked off in parallel to complete all testing
        5. once all jobs are completed, the pull request is reviewed by a developer and merged

        Show
        Jeff Ruch added a comment - I think some of the initial assumptions are no longer valid. The currently agreed upon process is: 1. developer creates feature branch (i.e. KULRICE-12345 ) 2. developer completes development and local unit testing 3. developer creates pull request to Master or rice-xx branch 4. pull request triggers multiple Jenkins jobs to be kicked off in parallel to complete all testing 5. once all jobs are completed, the pull request is reviewed by a developer and merged
        Hide
        Jeff Ruch added a comment -

        I tested using a shared build environment, with parallel downstream test projects and a join post build job. The github pull request builder plugin (gprb) did not recognize the downstream projects even with the 'Display build errors on downstream builds?' set to true. We even updated the plugin to the current version with no avail.

        I tried another approach. Breaking the tests out into multiple jenkins projects that are all triggered by the gprb worked nicely. By setting the messages of each job, it is easy to identify which jobs succeeded or failed from the github pull request. The only problem I found was that the status of the pull request gets set to 'success' even when other jobs are running. Once one of the jobs fails, the status is updated. This limitation will require the developer reviewing the pull request to verify a success message for each test. I think this is acceptable and the best solution at this time.

        Show
        Jeff Ruch added a comment - I tested using a shared build environment, with parallel downstream test projects and a join post build job. The github pull request builder plugin (gprb) did not recognize the downstream projects even with the 'Display build errors on downstream builds?' set to true. We even updated the plugin to the current version with no avail. I tried another approach. Breaking the tests out into multiple jenkins projects that are all triggered by the gprb worked nicely. By setting the messages of each job, it is easy to identify which jobs succeeded or failed from the github pull request. The only problem I found was that the status of the pull request gets set to 'success' even when other jobs are running. Once one of the jobs fails, the status is updated. This limitation will require the developer reviewing the pull request to verify a success message for each test. I think this is acceptable and the best solution at this time.
        Hide
        Jeff Ruch added a comment -

        I am going to expand my POC to include real data. I will configure a trigger word to ensure other pull requests don't kick off the POC jobs and vice versa.

        Show
        Jeff Ruch added a comment - I am going to expand my POC to include real data. I will configure a trigger word to ensure other pull requests don't kick off the POC jobs and vice versa.
        Hide
        Jeff Ruch added a comment -

        Completed basic proof of concept. A more complete POC should be done using the existing code / tests and github.

        Show
        Jeff Ruch added a comment - Completed basic proof of concept. A more complete POC should be done using the existing code / tests and github.

          People

          • Assignee:
            Jeff Ruch
            Reporter:
            Claus Niesen
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Agile

                Structure Helper Panel