Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Auditing Development Guidelines in GitHub Repositories


Published on

If your organisation has hundreds of code repositories you probably have some guidelines for them: how they are documented, how branches are protected, whether direct commits to master branch are allowed or only PRs should be used and all PRs should be reviewed, whether tests are run and code coverage is reported to PRs, etc.

Making sure that those guidelines are followed is a difficult task - even if all team members agree to do so, sometimes we simply forget or don't have time to implement the necessary changes.

Once we've agreed on our development guidelines, I was looking for a tool to automate such auditing for our team, so that in the same way as eslint can be used for testing code guidelines based on the rules, we could use this tool to audit our repositories in GitHub organisations. I couldn't find one so I created it.

Meet gh-lint - a rule-based command-line utility that audits all your GitHub repositories generating results in TAP (Test Anything Protocol) format that can be consumed by tap-github-issues reporter that can create, update and close issues in github repositories.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Auditing Development Guidelines in GitHub Repositories

  1. 1. Development Guidelines Evgeny Poberezkin @epoberezkin #fullstackcon
  2. 2. Why guidelines? Faster Easier Better
  3. 3. Which guidelines? 1. Code 2. Tests 3. Process
  4. 4. Code
  5. 5. History of guidelinesIt is good, as long as it works
  6. 6. There are bad parts
  7. 7. ESLint: you decide good and bad
  8. 8. Tests
  9. 9. Test-first vs debug-later
  10. 10. Process
  11. 11. Change process
  12. 12. Semantic commits chore: add Oyster build script docs: explain hat wobble feat: add beta sequence fix: remove broken confirmation message refactor: share logic between 4d3d3d3 and flarhgunnstow style: convert tabs to spaces test: ensure Tayne retains clothing
  13. 13. How do we know if we follow guidelines?
  14. 14. Existing tools? • Only validates names of commits, PRs, issues • Not extensible • Not open source • Great promise • Doesn't work
  15. 15. Demo Validate repositories against rules: Manage issues based on TAP report: Sample gh-lint config:
  16. 16. Questions? @epoberezkin