Check if a library repo has updates but no release.

[caternuson]

After the initial addition of a library to the bundle, any new release of that library will generate an update to the bundle. However, there are sometimes where a library has received some updates, but no release is done. This could be intentional or accidental.

Add some kind of check that can warn when this situation exists for any library included in the bundle.

[sommersoft]

I've got an early iteration running for this. It's using two API requests:

1. Request the latest release.
   • If no release is returned, the repo is flagged for needing a release.
   • If a release is returned, we use the published date for use in # 2.
2. Request any commits since the last release date.
   • If no commits are returned, we're all good and the repo isn't flagged.
   • If commits are returned, the repo is flagged for needing a release.

This is the only approach I could discern from the available API requests. The downsides are that it can increase the API requests by two for each repo (approx 800 total for 100+ repos; ~600 total without this), and also increases the time it takes adabot to run. Not huge deal breakers...

Now, with # 2, I'd like to filter the commits and ignore things that don't need releases; like /docs and repo management stuff (.travis.yml, etc). That will require an API request for each commit found, and balloon API requests and time-to-run.

Wanted to ask if those are acceptable trade-offs... @kattni @tannewt

EDIT: filtering by filenames in a commit (should've added repo name..hard to read the full func tree)

Getting info for commit: d972354bb1317278eac020ac879569be93564690
 > Commit files: .pylintrc
4500 requests remaining this hour
Getting info for commit: 61abf4100c4f18c42a43d188429a275bf105781d
 > Commit files: .pylintrc
Getting info for commit: c64d6f7fc14225655510947fc42b812caf359f67
 > Commit files: .travis.yml, README.rst
Getting info for commit: 02ed2b572f65cb4f0cc39be39e5317cc6490c0e6
 > Commit files: .travis.yml
Getting info for commit: 15ab6f55d3e5eeaffaff8e1f171070ec2f03fe75
 > Commit files: README.rst
Getting info for commit: 6f61755886f77bb311c383c05cb747069767ed54
 > Commit files: .pylintrc
Getting info for commit: 1c8dade7c005ec21434e33f4a7355e06ee17a561
 > Commit files: .pylintrc
Getting info for commit: b742c92eb7031d59a1a6f528db6b8013335208a3
 > Commit files: .pylintrc
Getting info for commit: 1c16273204eb05351cb8ab17779d6d80d042eb53
 > Commit files: .pylintrc
Getting info for commit: 8a9647bcc4a34a438106a301c35c9773b3e46d10
 > Commit files: adafruit_tsl2591.py
Getting info for commit: 584a24f3bc914618d15683a45fd1fe17373fbaab
 > Commit files: adafruit_tsl2591.py

[tannewt]

I was hoping this would be a single call to the API. I wonder how they do it for the releases page.

You are right that it takes multiple calls as is. I'd probably use the git commit hash instead because dates can get funny with commit ordering (merge and rebase can do funny things). That'll take three calls I think. release -> tag -> commit list.

I wouldn't bother with trying to detect commits we don't need to release. Instead, lets make releasing so easy we can do it on everything as needed.

[sommersoft]

I was hoping this would be a single call to the API.

So was I. But it turns out, we're in a little bit of luck. I didn't look close enough, or maybe outside of the box enough.

Compare two commits to the rescue!

Examples: https://api.github.com/repos/adafruit/Adafruit_CircuitPython_Bundle/compare/master...20181030 (today) will give us this little gem:

},
  "status": "identical",
  "ahead_by": 0,
  "behind_by": 0,
  "total_commits": 0,
  "commits": [

  ],

Back the compare up to the release-tag-before-last: https://api.github.com/repos/adafruit/Adafruit_CircuitPython_Bundle/compare/master...20181024

  "status": "behind",
  "ahead_by": 0,
  "behind_by": 10,
  "total_commits": 0,
  "commits": [

  ],

Ca ching! Keeps us at two API requests: 1) get latest release tag, 2) compare to master. I might be able to get the list of commits; docs say something about passing the correct 'media_type'. Will keep digging.

I wonder how they do it for the releases page.

Yeah, that's what lead me to believe there was some one-request-magic. Looking at a release page's source...there is a lot of buried JS on the server side, so they're keeping that secret to themselves.

[tannewt]

Two is awesome! Great find @sommersoft