I love the idea of a tool to help people build empathy and better understand the experience of someone with autism. I wonder what this simulator would be like from the perspective of a young child going through school. Is that something that sounds interesting to you that you would consider creating? Thanks for sharing.
Glad to hear Skaffold & Cloud Code are working well for you.
I wanted to note for others that there is a Cloud Code JetBrains plugin that also adds a workflow based on Skaffold to IDEs such as IntelliJ, PyCharm, etc. as well. Just like the Skaffold and the VS Code plugin, it also works with any K8s cluster.
As others have mentioned, there are many great solutions in the market for Kubernetes local iterative development. If you do decide to give Skaffold a try, I recommend checking out the File Sync feature (https://skaffold.dev/docs/pipeline-stages/filesync/) which enables you to continue making changes during a Skaffold iterative development session and have that code synced over to your running Kubernetes instance without having to rebuild or push images. When using Jib or Buildpacks to containerize your application, File Sync just works for Go, NodeJS, and Java but requires a little configuration for Dockerfiles.
FWIW, Skaffold is under active development and we're continuing to expand support for iterative development, CI and CD use cases as well as simplifying configs and general ease of use.
We also have a bunch of ways you can reach out to the team (https://skaffold.dev/docs/resources/) if you have any questions. We'd be happy to hear from you.
Yep, Cloud Shell Editor is based on the Eclipse Theia IDE Platform (https://theia-ide.org/) which embraces many of the VS Code design decisions and even directly supports VS Code extensions. That's what allows us to run the Cloud Code extension inside the Cloud Shell Editor.
Thank you for the praise, I'll pass it on to the team and I'm sure they'll appreciate it :)
I'm glad to hear you're enjoying the new Cloud Run support we've added to Cloud Code for IntelliJ. We'll get it added to Cloud Code for VS Code soon too for anyone else who is interested.
Also, thank you for submitting feedback via the user surveys - I read every single one and survey feedback, yours among others, absolutely was used to prioritize this work. If you have other features you'd like to see, please let us know.
A project as described here refers to a "Cloud Project" which is the basis for creating, enabling, and using all GCP services including managing APIs, enabling billing, grouping resources, etc. Within a project, one could have tens or hundreds of repositories. With 6 users on a single project, you would pay $1/month total (because the first 5 users are free) and all those users would have access to every repository in that project.
I appreciate your feedback that you find the pricing model and project concept difficult to understand. I'll bring this back to the team and we'll look at different ways to improve this.
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.
Thanks for taking a look. I'm glad you find Cloud Source Repositories interesting. We'd love to Cloud Source Repositories more practical to use. Can you explain what is impractical for you? Is the initial process of setting up multiple mirrors? Or the routine of having to go to another site for search?
(Disclaimer: I work at Google and am the PM on this product)
Cloud Source Repositories currently supports very large repositories. The same backend scales to the needs of the Android open source project, which regularly checks in massive binary files. There are many APKs and VM images in the Git repositories we host. However, Cloud Source Repositories does not support LFS or the mirroring of LFS content.
LFS is not deeply integrated into Git, creating usability problems. Because the content is not part of the object graph of the repository, you have to decide in advance to use Git LFS. You don't get the benefit in existing repositories with large files. You also can't back out --- once you're using Git LFS on a medium-sized file, you can't change your mind and instruct Git to send it inline in fetches, without rewriting history, which breaks existing clients that have cloned the repository.
For the same reason, history mining commands like "git blame" and "git log -S" don't have access to the object.
In addition, it complicates migrating to another host. Usually in Git, you can take out your content by running "git clone --mirror one-url and then "git -C directory.git push --mirror another-url". With Git LFS, this copies over the pointer files but not the underlying large file content and you must remember to take extra steps to instruct the new host about where the blobs are stored.
Google's Cloud Source Repositories team believes that Git itself needs to deal better with large files. The first step of this work within the Git project has been partial clone, which is supported in Cloud Source Repositories and in the public Git 2.17 release (for best results, please use Git 2.19, released September, 2018). If you run "git clone --filter=blob:limit=512M <url>", files larger than 512M will be omitted from the initial clone and fetched automatically on demand when needed (for example during checkout operations). See https://crbug.com/git/2 for more details about this feature. We are continuing to work with the community on adding other features related to large file support into Git.
(Disclaimer: I work at Google and am the PM on this product)
The code search functionality is the same as what Google engineers use internally. Cloud Source Repositories uses the same indexing and retrieval technologies on the same type of infrastructure.
As you mention, the more code you have, the more benefit you get from having fast search tools across your entire code base that can perform complex semantic and regular expression queries. Even with smaller codebases, I find it the fastest way to find the code I need.
(Disclaimer: I work at Google and am the PM on this product)
I'm glad you like it. Which languages would you like to see support added for?
Note that search works today across all languages but the semantic understanding of source which enhances search is limited to Java, JavaScript, Go, C++, Python, TypeScript and Proto files.
(Disclaimer: I work at Google and am the PM on this product)
We've generally heard that developers move from Bitbucket to Cloud Source Repositories because they want to use other Google Cloud services and it's simpler for them to manage their source in the same place where they debug, build and deploy that code. Developers often mention that they appreciate the unified identity, IAM permissions, and integrations that Cloud Source Repositories has with Cloud Shell, Cloud Build, Cloud Debugger and others Google Cloud services.
However, developers don't need to move from Bitbucket to take advantage of the utility provided by Cloud Source Repositories. You can mirror any number of your repositories into Cloud Source Repositories and take advantage of the code browser, code search, and various integrations with Google Cloud Platform.
(Disclaimer: I work at Google and am the PM on this product)