Allow detecting archived or disabled repos

[fingolfin]

This allows listing just "active" repositories in an organization. Right now, we have to manually exclude any such repository.

[fingolfin]

Huh, I don't understand those Travis errors... "uninitialized constant Faraday::Error::ClientError" ... ? Is this something caused by my PR, or a wider problem with the Travis tests?

[ashmaroli]

I don't understand those Travis errors

Please don't worry about the errors. It is caused by a second-order dependency (octokit > faraday) of this plugin. The error will resolve automatically once a new version of octokit gets released..

[ashmaroli]

@fingolfin The unrelated Faraday errors have been removed from this branch. The current failures are related to this PR. When possible, please look into getting those tests to pass again.

[fingolfin]

I had to fix script/webmock-repopulate and re-run it to get up-to-date webmocks. Let's see if that helps CI.

[fingolfin]

OK, that causes tons of errors in spec files.

Not sure how best to proceed. I could update those spec files of course (arguably, it would make sense to use up-to-date version of that JSON data). Or I could revert that part of the PR, and just hand-edit the webmock files to have the right keys in them. But I wonder if basing the tests on ancient versions of the JSON produced by GitHub is a good idea?

[ashmaroli]

I would suggest that you revert all changes that affect tests outside the scope of this pull request first and then tackle the failing tests incrementally..

[fingolfin]

That is the second option I listed: I could hand-edit the relevant JSON files to insert the required keys. That's easy enough to do, but seems rather... brittle to me. Is that really what you want?

I could also only update those webmock JSON files (by running script/webmock-repopulate) which are "needed" for testing the archived and disabled repos; but that doesn't substantially simplify the issue, I am afraid.

[ashmaroli]

@fingolfin You had two two options and asked for the best way to proceed.
I pointed you to the option that results in the most minimal diff for this PR which has a greater chance of being accepted for merge.
Now if you want to debate on or counter that suggestion, all that's going to lead to is noise and a stalemate...

IMO, the best way out is still to revert changes outside the scope of this PR and attempt to get the tests passing by manually editing spec/spec_helpers/integration_helper.rb

[fingolfin]

I did not want to debate, I just wanted to verify I understood what you were suggesting, to make sure I don't waste time on an approach that then is rejected later on shrug

[fingolfin]

All tests passed now except for one one AppVeyor, which I don't understand, as it complains about a mismatch for latest_release, but I didn't touch that.. It says:

...
Failures:

  1) integration into a jekyll site contains the correct latest_release
     Failure/Error: expect(subject[key].to_s).to match value

       expected "false" to match /assets_url/
       Diff:
       @@ -1,2 +1,2 @@
       -/assets_url/
       +"false"
     # ./spec/integration_spec.rb:30:in `block (3 levels) in <top (required)>'

[parkr]

Looking good!

https://developer.github.com/v3/repos/#get

[parkr]

@jekyllbot: merge +minor