Uploaded image for project: 'OpenShift Jenkins'
  1. OpenShift Jenkins
  2. JKNS-376

Setup HoneyBadger integration in CPaaS for Jenkins

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Major Major
    • None
    • None
    • jenkins-server
    • None
    • Pipeline Integrations #3252, Pipeline Integrations #3253, Pipeline Integrations #3254

      Story (Required)

      As a <PERSONA> trying to <ACTION> I want <THIS OUTCOME>

      <Describes high level purpose and goal for this story. Answers the questions: Who is impacted, what is it and why do we need it? How does it improve the customer’s experience?>

      As a developer, everytime a new OCPTools release is created we need to add the release branch of our Jenkins release. Through Honeybadger we can automate the creation of Errata Tool, Dist-git and comet. Otherwise, this requires a lot of manual effort.

      Background (Required)

      <Describes the context or background related to this story>

      Honey Badger is a release pipeline management and configuration service for Red Hat products. It automates updates on various Red Hat services such as the Errata ToolDist-Git, and Comet.

      Out of scope

      <Defines what is not included in this story>

      Approach (Required)

      <Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

      1. Open your release.yml configuration file present at your respective branch, add a pipeline called honeybadger
      1. Use the guide present at https://cpaas.pages.redhat.com/documentation/users/honeybadger.html to update the product.yaml to reflect the HoneyBadger changes.
      2. Post commit, run the honeybadger-pipeline for your CPaaS instance and a merge request will be created on https://gitlab.cee.redhat.com/pipeline/products
      3. Work with the release engineer to merge the MR.

      Dependencies

      <Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

      Acceptance Criteria (Mandatory)

      <Describe edge cases to consider when implementing the story and defining tests>

      <Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

      INVEST Checklist

      Dependencies identified

      Blockers noted and expected delivery timelines set

      Design is implementable

      Acceptance criteria agreed upon

      Story estimated

      Legend

      Unknown

      Verified

      Unsatisfied

      Done Checklist

      • Code is completed, reviewed, documented and checked in
      • Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
      • Continuous Delivery pipeline(s) is able to proceed with new code included
      • Customer facing documentation, API docs etc. are produced/updated, reviewed and published
      • Acceptance criteria are met

            diagrawa Divyanshu Agrawal
            diagrawa Divyanshu Agrawal
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: