waiverdb

Clone

#263 C3I job refactoring: new premerge and postmerge jobs to make the procedure more clear
Closed: Fixed 5 years ago by rayson. Opened 5 years ago by rayson.

Closed: Fixed
Reopen Issue

Currently, when a PR is created or merged, the following events happen:
- waiverdb-polling-for-prs/waiverdb-polling-for-masster is aware of the change, trigger a waiverdb-dev job run, and waits for it to stop.
- waiverdb-dev runs basic checks, unit tests, rpm build, container build, and an integration test (by triggering a waiverdb-integration-test job run), and waits for all sub tasks to complete.
- waiverdb-polling-for-prs/waiverdb-polling-for-masster updates the PR status/makes a comment on Pagure/sends an email about the results.

So waiverdb-polling-for-prs/waiverdb-polling-for-masster job runs can't quit until children job runs exit. Even further, the code of Jenkins-Pagure integration is in the polling jobs, make it hard to retire those polling jobs once UMB triggers are available.

Proposed New Design

The new design is to create 2 separated jobs waiverdb-premerge and waiverdb-postmerge for different workflows. waiverdb-premerge and waiverdb-postmerge will responsible for chaining jobs for needed tasks, and update the PR status or make a comment eventually. Like this:

Pre-merge

  1. waiverdb-polling-for-prs is aware of a PR creation or rebase, then trigger waiverdb-premerge, and quits without waiting. So the polling job will only focus on polling and triggering jobs. We can easily replace it once a UMB trigger is available.
  2. waiverdb-premerge triggers waiverdb-dev then waiverdb-integration-test, wait for the results, and finally update the PR status or make a comment to Pagure (When Greenwave supports pull-requests, we can inject the Greenwave decisions here).

Post-merge

  1. waiverdb-polling-for-prs is aware of a PR creation or rebase, then trigger waiverdb-postmerge, and quits without waiting. So the polling job will only focus on polling and triggering jobs. We can easily replace it once a UMB trigger is available.
  2. waiverdb-postmerge triggers waiverdb-dev then waiverdb-integration-test, waits for the results, trigger waiverdb-stage-integration-test then immediately quits. In the waiverdb-stage-integration-test job, results will be sent the ResultsDB via UMB (unimplemented).
  3. UMB triggers waiverdb-promote-to-stage when Greenwave says yes. Similar procedures for stage to prod.

Those reusable Jenkins jobs (like waiverdb-dev waiverdb-integration-test) may be replaced with Groovy function calls in the future if the shared library is introduced (https://pagure.io/waiverdb/issue/259).

Do you think this worth doing?

Yes, I think this is a great idea! I was actually just looking at the WaiverDB setup, to see how I could reuse it for Koji-MBS integration testing, and I admit that the flow was a little confusing. I think the design you propose is a lot simpler, and has the potential for improved reuse. A couple comments:

  • Post-merge 2. I think you mean waiverdb-postmerge.
  • I don't think waiverdb-postmerge should trigger waiverdb-stage-integration-test, I think it should just trigger waiverdb-integration-test and assuming that passes, tag the new image (built from the master branch) into dev.
    • Updating dev will cause a message to be sent by repotracker: https://datagrepper.engineering.redhat.com/raw?rows_per_page=50&delta=604800&category=repotracker
    • The message about the WaiverDB dev tag being updated should trigger waiverdb-stage-integration-test, which would test the WaiverDB dev image against stage images of ResultDB and Greenwave. This should report to ResultsDB.
    • If the Greenwave waiverdb-promote-to-stage policy (to be written) is satisfied, Greenwave will send a message.
    • That message should trigger the waiverdb-promoting-to-stage job, to tag the dev image into stage.
    • The WaiverDB stage tag being updated would trigger another message from repotracker, and the entire process would be repeated for stage-to-prod promotion.

I think this further decouples the jobs, and allows for greater use of ResultsDB and Greenwave. What do you think?

@mikeb I like the idea of further decoupling with repotracker. I will think it over and follow up your suggestions later.

One question, can you point me something about repotracker? Does a tag change in quay.io automatically trigger a repotracker message? What about docker-registry.engineering.redhat.com?

@mikeb Further thoughts on simplify the pipeline code. Many lines of code in the pipeline code is about passing and extracting the parameters (because we want to deploy many instances of CI pipelines). We can have a config file in the repo to reduce those parameters.

@rayson Sure, I've been meaning to record a demo explaining what repotracker is. I'll send you a link when it's available.

I think a config file is a good idea, if it will simplify the pipeline code.

@mikeb Thank you.

@mikeb I've added a JIRA card to my to-do list about the integration with repotracker.

Fixed by #292

Metadata Update from @rayson:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
5 years ago

Login to comment on this ticket.

Metadata
None
None
None
None
None
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.