PR Process Can Be Automatted

[theNerd247]

@unfoldingWord/devs @birchamp

@kintsoogi and @theNerd247 created the following steps for submitting a PR for a JS library that is a dependency in another app. I'm making a note of some issues I've discovered to start a discussion here.

Problems

• a PR is merged BEFORE it passes a QA process
• only a single consuming app is tested. Changes made to a library may work for one app but induce new bugs in other apps.

Improvements

• slowly start introducing a qa process for libraries that's independent of the consuming apps (this could be as simple as unit testing)
• create separate tickets for consuming apps and give a separate qa process for those (this idea closely relates to unfoldingWord/uW-Tools-Collab#7)

Current QA Process

1. in library let $betaVersion = $incrementPrereleaseVersion $newLatestVersion let $newLatestVersion = $incrementVersion $latestPublishedVersion
   1. publish $betaVersion to npm from local machine
   2. update package.json to $newLatestVersion
   3. Create a commit and push
   4. Create PR to merge into main/master branch let LibPrLink = PRlink let PRLibDesc = <write pr description>
      1. mark PR as draft
      2. add reviewers to PR
      3. set PR status to in review
      4. let AppReviewLinks = LibPrLink
   5. ∀.app ∈ consumer-apps
   6. checkout develop branch
   7. create a new branch
   8. update the <lib>@$latestPublishedVersion to <lib>@$betaVersion in app/package.json
   9. create a commit and push
   10. create a PR let PRLink let PRdescription = <write pr description> + <write testing steps> AppReviewLinks += PRLink These are done as part of the create new PR process
       1. mark PR as draft
       2. add reviewers to PR
       3. set PR status to in review
       4. PRdescription += <netlify deploy preview link>
       5. LibPRDesc += PRdescription
   11. ∀pr ∈ lib. if reviewPass pr (merge pr) (fix pr)
   12. in library
   13. pull and checkout to <main> branch
   14. publish $newLatestVersion to npm from local machine
   15. ∀pr ∈ consumer-apps
   16. if reviewPass pr
       1. update <lib>@$betaVersion to <lib>@$newLatestVersion (using yarn add)
       2. commit and push
       3. merge pr
       4. else (fix pr)
   17. ∀pr ∈ lib <> consumer-apps >> setAsInQAStatus pr
   18. Send discord message to QA (DM to Elsy, Daniel) with LibPrLink <> first AppReviewLinks <> IssueLink <> Git ShA (first consumer-app)
   19. ∀pr ∈ lib <> consumer-apps. if passQa pr (celebrate) (create new issues and start dev proces over)

[birchamp]

@theNerd247 @kintsoogi could this be simplified by having a RCL QA pipeline and an integration pipeline in zenhub? Then we could have QA test the component prior to integration.

Also in the consumer app steps above, step 7 needs to include moving the issue to the QA pipeline in Zenhub. The QA team checks that to see what's ready for testing.

[theNerd247]

the following link to this issue:

• https://github.com/unfoldingWord/tc-create-app/issues/1588
• https://github.com/unfoldingWord/uW-Tools-Collab/issues/3

[theNerd247]

I'd like to add cutting releases to this process as well:

here's the steps:

• in develop
  • let $releaseNumber = incrementVersion $currentVersionNumber
  • create release off of develop called $releaseNumber
  • create PR to merge into main for this
  • have the PR reviewed
  • once build succeeds and review is passed merge PR
  • tag main with $versionNumber
  • push new tag up
  • send notification in discord with release link

[theNerd247]

@birchamp

@theNerd247 @kintsoogi could this be simplified by having a RCL QA pipeline and an integration pipeline in zenhub? Then we could have QA test the component prior to integration.

I think so. Since RCLs are libraries I think separating their testing as far from apps as possible will increase their quality in the long term and make the QA process easier to follow.

[birchamp]

@theNerd247 Ok we can go back to that. We used to do that for tCC.