this post was submitted on 08 Jun 2023
3 points (100.0% liked)

Programming

13389 readers
152 users here now

All things programming and coding related. Subcommunity of Technology.

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago
MODERATORS
alyaza@beehaw.org
Hexorg@beehaw.org
remington@beehaw.org
3
What does your merge/code review process look like? (beehaw.org)
submitted 1 year ago by pattern@beehaw.org to c/programming@beehaw.org
7 comments fedilink hide all child comments
 

Hey all! My team at work is struggling with growing pains of getting into a formalized review process, so I was wondering if any of you guys have some things to live or die by in your code reviews. How much of it is manual, or how much is just static code analysis + style guide stuff, etc?

you are viewing a single comment's thread
view the rest of the comments
[–] cark@beehaw.org 1 points 1 year ago* (last edited 1 year ago)

Current place:

  • Work is done on a feature branch on a personal fork of the repo
  • Codebase requires 100% functional coverage, and you're responsible for writing the tests for your code and including that in the same PR
  • Run pre-commit hooks for style auto-formatters before you can commit and push your code to your origin fork
  • Ideally run local tests as well
  • Create a PR to pull feature branch into the upstream repo's main branch, which triggers the CI pipeline for style and tests
  • At least 1 other person must review the code before a PR can be approved and merged into upstream main
  • There's a separate CI pipeline for testing of publishing the packages to TestPyPI
  • Releases to PyPI are currently done manually