3 ms·

Interesting that they're going this way. We used Google's source repository functionality for a while because there is no real choice if you want to use Google

Interesting that they're going this way. We used Google's source repository functionality for a while because there is no real choice if you want to use Google Cloud Builder, which we were testing out for cloud-based Docker builds. GCB was pretty disappointing, and we moved off it. We also found the source repository service annoying. GCB can't pull code from Github, so you first have to set up a Google source repo and turn on Github sync; the source repo is, in other words, only there to be a mirror. Unfortunately, this introduces problems. You get latency -- your Google repo is always behind. Worse, we frequently experienced a situation where the sync was broken, either due to Github being flaky, or the syncing itself being flaky. In such cases, it was impossible to tell what the status of the sync was; all you could do was go into the UI and see that it was not up to date; no way to force a sync. So this setup became a liability. At the time (not sure if this is still the case), there was also no API to set up new mirrors, it was all manual. The whole UI around GCB and source repos seemed to have been created in a rush, very bare bones. A lot of Google serviced start out like this. I suppose this is a strategic play. For developers, you'd get a better UX if Google simply had tighter integration with Github and Gitlab, but Google probably doesn't want that. However, the low quality of their offerings so far (especially, cough, StackDriver) mean that this stuff will have an uphill battle in proving itself to developers, most of whom already have an allegiance to better tools like Github. If you're already on Github, why would you use this stuff?

mrep 8y ago
> Worse, we frequently experienced a situation where the sync was broken, either due to Github being flaky, or the syncing itself being flaky. In such cases, it was impossible to tell what the status of the sync was; all you could do was go into the UI and see that it was not up to date; no way to force a sync. Having worked for some of the big 5 American tech conglomerates, I would say this is the exact reason why they did not support it initially nor fully. The bigger the company, the more risk their is running/depending on someone else's software SLA/scaling/dependencies/security/privacy/laws... You just had a bad experience with Google cloud but you don't really know if it was google's fault or Githubs. Plus, they have so many software developers, they can build their own version that conforms to their requirements themselves for practically the same costs.
russellwolf 8y ago
Cloud Source Repositories PM here. I appreciate your feedback and will share it with the team. >it was impossible to tell what the status of the sync was; all you could do was go into the UI and see that it was not up to date; no way to force a sync. We've heard this was a problem for users so we're adding the ability to force a sync and to view the current sync status. These features will be live in the next few weeks.
- atombender 8y ago
  I would strongly advise you to make the mirroring system completely hidden. It's weird to me that the UI even exposes this. First, have people register their origin repos. In fact, don't let people register individual repos; just their accounts or organizations. So instead of "Source Repositories", it's just a list of repos that GCP has access to. Then, behind the scenes, mirror everything you have access to. All projects that you can read. Keep it internally. If you offer a UI to browse code and so on, pretend the code is remote. All references need to show https://github.com/someorg/myrepo.git https://github.com/someorg/myrepo.git as the remote, for example. Pretend your mirror doesn't exist. Only add Github hooks for projects where real-time syncing is needed, i.e. build triggers. Then, use Github hooks like you usually do, but have it fall back to pull-based polling when hooks aren't working (something I bet you guys can detect simply by noticing that hook activity for all projects is below average!). Anything that needs a build trigger could also have a manual button that checks the upstream. Consider the developer's perspective. I already have my code on GH. I don't want to also store it in GCP. Why should I? It's right there on GH for any API consumer to read. Keeping it on GCP is just more work. Being able to build with GCB without involving the indirection of a mirror would be even better.
  - dragonwriter 8y ago
    > Consider the developer's perspective. I already have my code on GH. What if you don't? The fact that Google needs to acknowledge that CSR isn't where existing projects are primarily hosted (and thus needs to accommodate projects primarily hosted elsewhere) doesn't mean they shouldn't try to be a primary host.

mrep 8y ago

> Worse, we frequently experienced a situation where the sync was broken, either due to Github being flaky, or the syncing itself being flaky. In such cases, it was impossible to tell what the status of the sync was; all you could do was go into the UI and see that it was not up to date; no way to force a sync. Having worked for some of the big 5 American tech conglomerates, I would say this is the exact reason why they did not support it initially nor fully. The bigger the company, the more risk their is running/depending on someone else's software SLA/scaling/dependencies/security/privacy/laws... You just had a bad experience with Google cloud but you don't really know if it was google's fault or Githubs. Plus, they have so many software developers, they can build their own version that conforms to their requirements themselves for practically the same costs.

russellwolf 8y ago

Cloud Source Repositories PM here. I appreciate your feedback and will share it with the team. >it was impossible to tell what the status of the sync was; all you could do was go into the UI and see that it was not up to date; no way to force a sync. We've heard this was a problem for users so we're adding the ability to force a sync and to view the current sync status. These features will be live in the next few weeks.

atombender 8y ago
I would strongly advise you to make the mirroring system completely hidden. It's weird to me that the UI even exposes this. First, have people register their origin repos. In fact, don't let people register individual repos; just their accounts or organizations. So instead of "Source Repositories", it's just a list of repos that GCP has access to. Then, behind the scenes, mirror everything you have access to. All projects that you can read. Keep it internally. If you offer a UI to browse code and so on, pretend the code is remote. All references need to show https://github.com/someorg/myrepo.git https://github.com/someorg/myrepo.git as the remote, for example. Pretend your mirror doesn't exist. Only add Github hooks for projects where real-time syncing is needed, i.e. build triggers. Then, use Github hooks like you usually do, but have it fall back to pull-based polling when hooks aren't working (something I bet you guys can detect simply by noticing that hook activity for all projects is below average!). Anything that needs a build trigger could also have a manual button that checks the upstream. Consider the developer's perspective. I already have my code on GH. I don't want to also store it in GCP. Why should I? It's right there on GH for any API consumer to read. Keeping it on GCP is just more work. Being able to build with GCB without involving the indirection of a mirror would be even better.
- dragonwriter 8y ago
  > Consider the developer's perspective. I already have my code on GH. What if you don't? The fact that Google needs to acknowledge that CSR isn't where existing projects are primarily hosted (and thus needs to accommodate projects primarily hosted elsewhere) doesn't mean they shouldn't try to be a primary host.