Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloud Source Repositories

cloud.google.com

Post reply on HN
Print view View original

31–40 of 74 posts

Re: Cloud Source Repositories

#31

Post by mrep »

atombender wrote: post #22

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 a…

> 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.

Re: Cloud Source Repositories

#32

Post by russellwolf »

atombender wrote: post #22

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 a…

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.

Re: Cloud Source Repositories

#33

Post by russellwolf »

tekkk wrote: post #18
manigandham wrote: post #7

Earlier quoted context omitted.

It's just git so there's not much sophistication, nor is one service "better" than another in that regard. Github/Gitlab are still far more useful as they are more than just repos. The issues, PRs, wikis, and general management features are what most projects need. Azure DevOps is probably the best competitor from the clouds.

Sure git is just git. I was referring more to the other features this PR piece is promising: Fast Code Search, Debug in production, Detailed audit logs. I am curious how they relate to say Github or other services. Also as a sidenote, the Quickstart link for Debug in production and Detailed audit logs is the same. Is it so for a purpose?

Cloud Source Repositories PM here.

>Also as a sidenote, the Quickstart link for Debug in production and Detailed audit logs is the same. Is it so for a purpose?

Thanks for pointing this out. It's not intentional. I'll make sure it gets fixed.

Re: Cloud Source Repositories

#36

Post by russellwolf »

zawerf wrote: post #28

Code search might be the killer feature here. I used to work at google many eons ago and I spend 90% of my day wading through billions LOCs with their internal code search tool. I believe it's the same one used by chromium: https://cs.chromium.org/

Cloud Source Repositories PM here.

It is indeed using the same code search infrastructure as the Chromium code search site as well as the Google internal code search site.

You can read more about the Cloud Source Repositories code search feature in a blog post here: https://cloud.google.com/blog/products/application-developme...

Re: Cloud Source Repositories

#37

Post by atombender »

russellwolf wrote: post #32
atombender wrote: post #22

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 a…

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 wee…

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 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.

Re: Cloud Source Repositories

#38

Post by dickeytk »

tl;dr: this isn't replacing github, it's solving a more specific problem

I think everyone here is missing the point. The purpose here seems to be similar to github actions in providing workflows around repository events (though also including some basic ability to view the code as well). Having a clean way to cut a release that updates app servers on app engine and serverless functions in tandem is needed right now.

I don't think this is intended to be used by anyone that doesn't have their platform on GCP.

For highly sensitive codebases within an organization, they may not want to host it on microsoft's servers as well—but this seems secondary to the workflow functionality.

It's possible I'm incorrect though and I do think the messaging here should be improved. Chiefly that it shouldn't lead with "Unlimited private Git repositories for free"

Re: Cloud Source Repositories

#39

Post by skj »

derefr wrote: post #17
013a wrote: post #14

My biggest complaint with Google Cloud's UX, which applies to their new Cloud Source Repositories opt-in UI: They shard out so many of their user experiences into different websites and domains. Under the umbrella of Google Cloud you've got Google Cloud Console, Firebase, Stackdriver, Source Repositories, Dialog Flow, probably a couple others I'm forgetting. Almost all of these have entries on the Google Cloud Consol…

> I want to see a better unifying vision for what being a Google Cloud customer actually means The thing you've got to understand is that none of these products are "Google Cloud" products. They're Google services (or, even moreso, services of random third parties which Google has acquired) that you happen to be able to hook into from your GCP project and access through the GCP CLI. The closest comparison I can think…

I can tell you that your view does not match that of the engineers working on these products. If something is namespaced under a project and you use the cloud console or CLI to manage it, it is very much a GCP product.

(I am one such engineer, and have worked on the CLI, cloud build, and container services)

Re: Cloud Source Repositories

#40

Post by scarface74 »

user5994461 wrote: post #21
cdoxsey wrote: post #12

It wasn't all that long ago that Google shut down Google Code. They said: https://opensource.googleblog.com/2015/03/farewell-to-google... > After profiling non-abusive activity on Google Code, it has become clear to us that the service simply isn’t needed anymore. And now they've created a new product which does pretty much the same thing... Wonder how long this one will last.

Well, there was at least one legitimate reason to shut it down. It was used to host malware/phishing disguised as official google software under the official umbrella of google.com. What could go wrong with downloading chromebeta from google itself? That being said, the tool to migrate to GitHub worked well. It was an easy migration.

Well that was better than SourceForge. SourceForge actively added crapware to open source code.
Post reply on HN