https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/ Recent content in Codebase Maintenance on Handbook Hugo -- gohugo.io https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/hygiene-of-directories-structure/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/hygiene-of-directories-structure/ Readme The current structure of our monorepo is listed in the root-level README.md file. In addition to that this files contains a summary of our github actions builds statuses. It is the responsibility of the monorepo maintainer to ensure that new additions to the monorepo are placed according to the structure; when necessary make changes to the structure; keep README.md up-to-date. Keep the source not the output This is general rule applied to everyone to avoid adding to git those files that can easily be generated using the necessary scripts. https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/pr-review/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/pr-review/ You were asked to review a PR? Here’s what you should keep in mind: General approach By default we don’t do in-depth review of everything unless it was specifically requested. Sometimes PRs are just too big to review everything, and more often than not it would’ve been a waste of time. So it’s a responsibility of the person who asks for a review to clearly specify what needs to be carefully reviewed, unless the scope of the PR is very limited and the subject of review is crystal clear. https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/branch-review/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/branch-review/ On github page of our monorepo, go to branches -> All branches. In the perfect world you should only see gray or green PR icons and all PRs should not stay inactive for more than 2 months. Gray indicates a draft PR that is in progress. Green means a PR that is ready to be reviewed. The whole process of branch review is essentially about achieving this perfect picture. We have a recurring Jira issue which pops up every two weeks and assigns one person to do the branch review. https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/github-builds/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/github-builds/ Overview Workflow yaml files Triggers Initial job setup Environment variables Steps Overview Before pushing package updates to github you should always run R CMD check to make sure that you did not break any CRAN standards and that all the tests continue to run well. But still, to be on the safe side, we run R CMD checks in an automated way using github actions. https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/github-builds-fixing/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/github-builds-fixing/ General recommendations Difficulties in preconfiguring the build environment Inconsistencies between your working environment and the one on GitHub Temporary issues Resolving Build Issues: An Example General recommendations To begin with, it is crucial to first ensure that the build functions properly in your normal working environment, that is in RStudio. If the build runs well in your working environment yet encounters problems on GitHub, the underlying cause is almost always related to one of the following: https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/internal-cran/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/internal-cran/ Overview Our Internal CRAN is a repository of all our internal packages, similar to the original CRAN, but exclusive to us and not open to the world. It allows us to easily install our packages using the standard install.packages() command and contains all versions of our packages. While it only contains sources and not binaries, resulting in longer installation times, it is easier to maintain this way. The latest versions of our packages are automatically added to our internal CRAN through a Github build process. https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/codebase-maintenance-overview/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/devops/codebase-maintenance/codebase-maintenance-overview/ Almost all coding we do ends up in our big main github repository, or as we call it, the monorepo. There are a few exceptions, but these are not going to be considered in this section of the handbook. Because the monorepo is so huge and because multiple people actively work on it in parallel, it is critically important to keep it in order. To achieve this we have a set of rules and processes we follow.