Should SSH access be checked in the master repo? about core

[orta]

odd I thought we were linking for making sure all github links used https.

[neonichu]

Nah, the goal is to not fail on private spec repos, see #83. The GitHub check only verifies that you don't use http.

[squarefrog]

https://github.com/CocoaPods/Core/blob/master/spec/specification/linter_spec.rb#L266-L276

I don't suppose there is a method to check if the repo is the master? Maybe a kludgey hack would be to check if the lint is running on Travis LOCALLY in the master repo, but that definitely makes me feel uncormfortable enough that it is not the correct solution

[neonichu]

It is already failing on Travis, though, with a somewhat understandable error message.

Personally, I can only see the goal to have people realise this before making a PR, for that the lint commands would need a switch to specify they are for the master repo or one to specify that they are for a private one.

[squarefrog]

I'm sorry yes that was a mistake on my part - I believe the issue was I linted the file locally and it passed which confused me when providing support in Specs.

It's definitely something I can manually look out for now, but it could be an opportunity to clear things up when locally linting.

[fabiopelosin]

@neonichu when trunk will be introduced that full check performed by Travis will be removed (because waiting for the pull-request made Trunk too much complex... if I'm correct... @alloy ?). So @squarefrog makes sense in my opinion.

We could pass to the Validator whether we are submitting to the master repo and in that case run additional checks.

[neonichu]

Ah, I see.

I would suggest assuming the master repo by default and passing something to the Validator if some other spec repo is used. That way it would do the right thing for inexperienced users.

[squarefrog]

👍

[alloy]

because waiting for the pull-request made Trunk too much complex... if I'm correct...

@irrationalfab Aye, it adds complexity while not educating spec authors, as some use it as a way to get their specs in order instead of trying in a real app etc.

[alloy]

I agree with @neonichu.

At some point it might be nice if you could have a default options config inside a spec repo. That way private spec repos could indicate what type of linting they want etc.

[fabiopelosin]

At some point it might be nice if you could have a default options config inside a spec repo. That way private spec repos could indicate what type of linting they want etc.

Is there any benefit in maintaining this?

[alloy]

The idea is that you then no longer have to specify certain options for certain repos. However, this only makes sense if we really really really need options at all.

[fabiopelosin]

I think that having a higher set of checks for just the master repo is simpler and sufficient for the moment.