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

Introducing Google Cloud Container Builder

cloudplatform.googleblog.com

Post reply on HN
Print view View original

101–110 of 114 posts

Re: Introducing Google Cloud Container Builder

#101

Post by tracker1 »

skj wrote: post #30
oakhaven wrote: post #27

Earlier quoted context omitted.

I went through the doc. Yes, in addition to Dockerfile, there is a way to run tasks in parallel. I'm not sure how killing of a feature that is, when every build tool lets you pass a job count. And beside that, I can't think of a legit use-case of what to run side by side in a container build. Maybe someone else knows/cares? I've never built anything with JDK, but is cleanup of build dependencies really a problem in 2…

The difference between including the JDK vs only the JRE in your deployable image can mean hundreds of megabytes saved. If you're trying to roll out this image to hundreds or thousands of nodes, this can save a lot of resources. Additionally, less in your deployable is better from a security standpoint. re lock-in: We're definitely cognizant of lock-in issues, and were trying to make it as friendly as possible. In th…

Agreed, my node builds tend to build to a ./dist including a separate package.json with all test/dev bits completely removed. From there I pretty much use the -onbuild containers from the dist/ path.

Re: Introducing Google Cloud Container Builder

#102

Post by aleksharma12 »

alpb wrote: post #70
pbiggar wrote: post #66

Earlier quoted context omitted.

Question: was this on regular CircleCI, or the v2 beta?

Regular Circle CI. I do not have access to the v2 beta. For comparison here is the same Dockerfile built with Circle CI, it took 3m30s: https://cl.ly/0U1c2Q1n2S20/Image%202017-03-06%20at%209.50.31... and Google Cloud Container Builder: https://cl.ly/3E1c3l1L2Q3o/Image%202017-03-06%20at%209.52.01... although Cloud Container Builder does not list how long each step it takes, it totals 1m10s.

Hey, Dev Advocate at CircleCI here:

Saw that you didn’t have 2.0 beta access; we’re actually opening that up to everyone this week, so keep an eye on our docs over the next few days. Biggest features you probably care about are the faster speeds/improved caching and native Docker support.

Re: Introducing Google Cloud Container Builder

#103

Post by kmicklas »

dottedmag wrote: post #78
kmicklas wrote: post #50

Earlier quoted context omitted.

Agreed, Nix the language is probably unnecessary. (The main benefit I can think of is avoiding depending on the moving target that is basically any other scripting language they could have tried to co-opt.)

To be fair, Nix language is completely different from other languages out there -- it employs only immutable data structures -- so using another language would not be possible. It does not excuse Nix to have such a braindamaged^W esoteric syntax.

> To be fair, Nix language is completely different from other languages out there -- it employs only immutable data structures -- so using another language would not be possible.

I don't think the immutability is actually important. Only derivations (which are basically language agnostic) need to be immutable/hashable.

> It does not excuse Nix to have such a braindamaged^W esoteric syntax.

What's so bad about it? The main pain point I've found with it is the lack of documentation for builtin functions. The syntax seems fine to me.

Re: Introducing Google Cloud Container Builder

#104

Post by hiroshi3110 »

skj wrote: post #11

Hi all, I'm on the eng team for this service. Happy to answer any questions, and I'll do my best to monitor the threads.

You support Github push hook. Any plan to give us CI status? For now, I'll create a CI status with curl... https://developer.github.com/v3/repos/statuses/

Re: Introducing Google Cloud Container Builder

#105

Post by tonglil »

lobster_johnson wrote: post #53
skj wrote: post #11

Hi all, I'm on the eng team for this service. Happy to answer any questions, and I'll do my best to monitor the threads.

This looks great. One question: We're currently using Drone (the open-source self-hosted version), which allows us to define a number of parallel sidecar containers ("compose") as part of the build pipeline. We start things like PostgreSQL and Elasticsearch like this because a lot of tests need to exercise the actual data storage instead of (or in addition to) mocking/emulating them. The container builder thus double…

I agree, the semantics required to define the build in GCCB seems really limiting, going to stick to Drone until this matures a bit. The plugin ability of Drone really outshines the current as well.

Re: Introducing Google Cloud Container Builder

#107

Post by skj »

tonglil wrote: post #106
skj wrote: post #11

Hi all, I'm on the eng team for this service. Happy to answer any questions, and I'll do my best to monitor the threads.

The pricing page doesn't mention any information about data ingress/egress. Care to clarify please?

The cloudbuild service operates some other services on your behalf, and their relevant charges apply.

This most notably includes Cloud Storage (GCR is backed by Cloud Storage). If you use 'gcloud container builds submit' to kick off a build, Cloud Storage is used to get the source in as well.

Re: Introducing Google Cloud Container Builder

#108

Post by skj »

hiroshi3110 wrote: post #104
skj wrote: post #11

Hi all, I'm on the eng team for this service. Happy to answer any questions, and I'll do my best to monitor the threads.

You support Github push hook. Any plan to give us CI status? For now, I'll create a CI status with curl... https://developer.github.com/v3/repos/statuses/

We don't have any direct support of GitHub status updates. You can make whatever requests from within the build (presumably at the end), but we don't (yet!) have a supported way to get secrets into the build for access to POST the new status.

GCCB will also publish on Cloud Pub/Sub when the build's status changes (including when it goes to "SUCCESS" or "FAILURE"), and you can tell Cloud Pub/Sub to make POST requests with that data, but the format is not flexible so it might not work out for GitHub status updates.

Re: Introducing Google Cloud Container Builder

#109

Post by hiroshi3110 »

skj wrote: post #108
hiroshi3110 wrote: post #104

Earlier quoted context omitted.

You support Github push hook. Any plan to give us CI status? For now, I'll create a CI status with curl... https://developer.github.com/v3/repos/statuses/

We don't have any direct support of GitHub status updates. You can make whatever requests from within the build (presumably at the end), but we don't (yet!) have a supported way to get secrets into the build for access to POST the new status. GCCB will also publish on Cloud Pub/Sub when the build's status changes (including when it goes to "SUCCESS" or "FAILURE"), and you can tell Cloud Pub/Sub to make POST requests…

Thanks. On build failure the last step are not executed I think. So I'll check cloud pub/sub.

BTW, are there any community or (public) support channel out there? You know a HN thread is not a permanent place.

I searched on SO, but no label of google cloud container builder yet. http://stackoverflow.com/search?q=google+cloud+container+bui...

Re: Introducing Google Cloud Container Builder

#110

Post by derefr »

dottedmag wrote: post #78
kmicklas wrote: post #50

Earlier quoted context omitted.

Agreed, Nix the language is probably unnecessary. (The main benefit I can think of is avoiding depending on the moving target that is basically any other scripting language they could have tried to co-opt.)

To be fair, Nix language is completely different from other languages out there -- it employs only immutable data structures -- so using another language would not be possible. It does not excuse Nix to have such a braindamaged^W esoteric syntax.

A programming language that "employs only immutable data structures" is effectively a macro processor language, no? Like https://en.wikipedia.org/wiki/M4_(computer_language) .
Post reply on HN