Other git hosts about strider HOT 21 CLOSED

I've had interest in support for Bitbucket and also Github enterprise.

I'd love to see these (and Gitlab too - looks awesome!) supported by Strider and I'd be happy to accept pull requests - but it's not a priority at this time for me personally to develop unless a paying customer requests it.

from strider.

I'm interested in adding support for manually configuring a git uri that can be used to pull data from, and a generic webhook implementation that works for various git providers and curl.

Looking at the code it seems the current implementation is rather tightly coupled with github, which seems unfortunate for this purpose. Do you have any thoughts about this, @niallo?

from strider.

It would definitely be a huge step in the right direction to decouple from github. I think in most places, having a "githost" attr in the repo_config would do the trick. It would be a good idea to define a spec for our repo_config; currently we're just dumping in what github gives us, which is definitely way more than we need.

from strider.

Repo_config does have a spec:

https://github.com/Strider-CD/strider/blob/master/lib/models.js#L58

However, plugins can extend it.

The Github data that is persisted is a cache more than anything else.

Agree that the current code is coupled to Github, but like @jaredly states it would be totally possible to make it more generic.

The hard part is actually the UI side IMHO, not the backend. How do you not overload the user with complexity while presenting options for other Git hosts?

The repo setup flows and configuration are already too complicated. If we can do this in a way that doesn't add a ton of UI complexity I'm totally onboard.

from strider.

Well manual setup is no problem (where you give the git URL) once we
decouple from github.... and I think allowing people to register with
multiple git hosts wouldn't be that bad. What do you mean by "too
complicated"?

On Sun, Jul 14, 2013 at 1:37 PM, niallo [email protected] wrote:

Repo_config does have a spec:

https://github.com/Strider-CD/strider/blob/master/lib/models.js#L58

However, plugins can extend it.

The Github data that is persisted is a cache more than anything else.

Agree that the current code is coupled to Github, but like @jaredlyhttps://github.com/jaredlystates it would be totally possible to make it more generic.

The hard part is actually the UI side IMHO, not the backend. How do you
not overload the user with complexity while presenting options for other
Git hosts?

The repo setup flows and configuration are already too complicated.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-20942264
.

from strider.

One of the things we're trying to accomplish with Strider is not get in the way of the user. Avoid asking the user a ton of questions, to the extent that we can automatically set up CI and CD - just do it.

Strider isn't about tons of knobs - Jenkins already does that for people who like knobs.

So setting up a Github repo for CI in the best case should require almost no configuration (right now this works well for node and pretty well for python).

80+% of people are using Github (or Github Enterprise), or will be in the near future. What I'm saying is we shouldn't make the experience worse for the 80% case.

from strider.

totally. I'm all over that.
I do think all the github logic should be extracted into an extension
though. Then it would be simple to make a bitbucket extension, etc.

On Sun, Jul 14, 2013 at 1:57 PM, niallo [email protected] wrote:

One of the things we're trying to accomplish with Strider is not get in
the way of the user. Avoid asking the user a ton of questions, to the
extent that we can automatically set up CI and CD - just do it.

Strider isn't about tons of knobs - Jenkins already does that for people
who like knobs.

So setting up a Github repo for CI in the best case should require almost
no configuration (right now this works well for node and pretty well for
python).

80+% of people are using Github (or Github Enterprise), or will be in the
near future. What I'm saying is we shouldn't make the experience worse for
the 80% case.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-20942598
.

from strider.

We should talk about how make this doable by extensions. It is obviously possible but would require pretty invasive changes and could easily break stuff.

This should be done in close co-operation with someone who actually uses non-Github services though. We use Github for everything and so do all our customers - we simply don't have a motivation to do this right now. We'd
rather spend our time on other features.

Of course if someone was willing to fund FrozenRidge LLC to develop this we'd do it :-)

from strider.

sure :)
I think first step is just a bit of decoupling to enable non-github custom
repos.
Anything beyond that can wait

On Sun, Jul 14, 2013 at 2:08 PM, niallo [email protected] wrote:

We should talk about how make this doable by extensions. It is obviously
possible but would require pretty invasive changes and could easily break
stuff.

This should be done in close co-operation with someone who actually uses
non-Github services though. We use Github for everything and so do all our
customers - we simply don't have a motivation to do this right now. We'd
rather spend our time on other features.

Of course if someone was willing to fund FrozenRidge LLC to develop this
we'd do it :-)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-20942798
.

from strider.

I'd also like to see support for "dumb" Git URLs. My company's too cheap to plump for GitHub Enterprise and has instead gone with Stash. My team also uses Gitblit. Both are quite limited in terms of API support, but I can roll my own support externally through the use of post-receive hooks if Strider made the webhooks interface more generic (it may already be) and could just do a "git clone".

from strider.

In the very near future, it will be really simple to make a plugin to integrate with stash, gitblit, or whatever you want. I'm in the process of generalizing the way we represent jobs to afford this.

from strider.

I'd like to see the github enterprise support 👍

from strider.

GH:E support would be awesome.

from strider.

This is one of the features I'm actively working on :) it'll be awesome.

On Tue, Aug 20, 2013 at 1:25 PM, Brian Lalor [email protected]:

GH:E support would be awesome.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-22970710
.

from strider.

Added to Strider 1.4.x milestone

from strider.

Implemented in 1.4.

from strider.

@niallo I see this is in the roadmap for 1.4, but don't see a commit ref in your last comment. Has this already been completed or just added to the milestone? Lastly, will it be host agnostic or only work with a specified set of other providers?

Thanks.

from strider.

two things:

• manual add of a git repository is totally agnostic, but you don't get tight integration
• provider plugins allow tight integration with hosted services, and they're really easy to put together. see strider-github and strider-bitbucket

from strider.

Ah, this is perfect! I'm guessing this isn't published in npm yet? If I wanted to get this up & running now I'd need to manually clone the repo?

from strider.

That's right. Once we iron out some more bugs and get the tests into a good
place, we'll release 1.4

On Fri, Nov 8, 2013 at 4:04 PM, brennebeck [email protected] wrote:

Ah, this is perfect! I'm guessing this isn't published in npm yet? If I
wanted to get this up & running now I'd need to manually clone the repo?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-28105482
.

from strider.

Got it. Thanks.

I'll give it a run anyway 😄

from strider.