Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Automate the creation of feature builds (FB)

Description

Synopsis
To avoid regression and human errors when contributing to PMM we have to automate the process of creating the feature builds. Right now its manual and we are facing the following downsides:

  1. Sometimes we branch off of a wrong commit (say, the source branch may not be the most recent one and therefore it may not include the latest features, fixes etc.)

  2. We do not validate the feature branch with a successful test run. In other words, nothing prevents us from accidentally merging a feature branch while tests fail.

Therefore, automating the creation of feature builds seems to be a solution to this problem.

Disclaimer

While we automate the creation of feature builds, we still want to keep the current flow (manual creation of FB) since there may be use cases when this may be necessary.

The Story

1/ As a developer, I am able to create a feature branch (fix, hotfix) and submit a pull request. Once the pull request is submitted, I will be notified on the following system events:
 a) the system creates a feature build and provides me with a link to it
 b) the system starts running the tests against the feature build
 c) the system finishes running the tests and I receive a link to the test results (either positive or negative)
 d) if the step c) gives a positive test result the system notifies the reviewers suggesting to proceed with review

2/ As a system I will keep the merge button disabled until all of the following takes place:

 a) a feature build is created (the developer's feature branch is merged into it)
 b) the tests have successfully run against the feature build
 c) the feature branch has been reviewed and there are no pending request change requests

3/ As a system I will delete the relevant feature build once the pull request is merged to the master (not any other!) branch.

Open Questions

  • maybe need a naming convention

  • do we still need pmm-submodules?

 

How to test

None

How to document

None

Attachments

1

Smart Checklist

hide

Activity

Show:

Alex Demidoff March 6, 2020 at 3:25 PM
Edited

All the checks should be successful, otherwise why would we need to run them?

Roma Novikov March 6, 2020 at 11:10 AM

Let me  give us one example, where  I believe we can do  "easy win":

https://github.com/percona/grafana-dashboards/pull/621  - This is PR to add some changes. It can be merged because only an unrequired check is failing.

But!  This  PR has linked FeatureBuild  https://github.com/Percona-Lab/pmm-submodules/pull/736  and it's NOT good, because of Jenkins results

So it looks like if  we can Block  Original PR (to Grafana-dashboards)  before  Jinkins  job  from related  Submodules  build (https://pmm.cd.percona.com/blue/organizations/jenkins/pmm-submodules/detail/PR-736/2/pipeline ) not  Green  - we can get some  good process enforcement )

 

 

Puneet Kala March 2, 2020 at 8:21 AM

thanks for the description.

I think this should be an epic, because it will need changes in the build process, Jenkins job, QA testing jobs and maybe more, also it would be better to create a task on that Epic and lets start with smaller block, first we should try on `grafana-dashboard` repo, see how it goes and bottlenecks. etc.

 
Basically having the big picture in mind and taking one baby step at a time to achieve this
cc
 

vasyl.yurkovych February 28, 2020 at 1:48 PM
Edited

i think ability to Merge should not depend on a Test Run result , sometimes it could be false positive test result

Can be, but there have to be clear rules. You either have to fix it or mute it. Only then you will be able to merge. 
Moreover, a false positive is a bug per se. Another reason to get rid of it.

Details

Assignee

Reporter

Priority

Components

Labels

Needs QA

Yes

Needs Doc

Yes

Smart Checklist Progress

Smart Checklist

Created February 28, 2020 at 9:58 AM
Updated August 8, 2024 at 4:59 AM
Configure