Hacker News new | ask | show | jobs
by _5meq 2881 days ago
This is their container builder project re-branded.

Pretty nice product, but missing some LAUGHABLE features.

Specifically:

- Ability to start builds based on github pull requests

- Ability to send messages to slack on successful / failed builds

- Ability to update github PRs with build status

- Conditional build steps AT ALL

- Ability to start parameterized builds from GUI ( What if I want to deploy to a specific environment? )

- Any outside integrations AT. ALL.

- No story on how to store secrets

I've been running this product for about a year. I have a Jenkins job that detects github PRs, and then launches these builds. I would LOVE to delete that Jenkins VM, but for some reason a lot of basic functionality has been ignored.

edit:

People have informed me that Github PR building is in alpha! PRAISED BE THE GOOGLE!

https://cloud.google.com/cloud-build/docs/run-builds-on-gith...

4 comments

Hi, member of the Google Cloud Build team here. Appreciate all the feedback on the launch! Yes it's both a rebrand as well as an update.

When we first launched Container Builder a year ago we always had a plan to support more CI use cases. With the launch today we've added a few new features such as:

- Built-in support for pushing non-container artifacts to Google Cloud Storage

- Filepath triggers for invoking builds only on changes to certain subdirectories or files

- Updates to the Cloud Console UI and of the Cloud SDK (from `gcloud container builds...` to `gcloud builds...`)

We have more updates in alpha now including built-in support for GitHub pull requests, status/Checks API support, and programmatic triggers, which we agree is one of the biggest missing pieces for many people. That GitHub app is the first step with more granular control over PR triggers coming soon.

We try not to comment on roadmap items but looking ahead a little, this rebrand is also an indication of the product's focus on broader CI/CD use cases, which many of our users are already using Cloud Build for, and an evolution towards bringing DevOps and Continuous Integration best practices to Google Cloud users. Feature requests like built-in conditional steps and notifications are on our radar and we always appreciate hearing from users what they'd like to see us prioritize.

Release notes are published here for anyone interested in updates on new features. https://cloud.google.com/cloud-build/release-notes

There's a public Slack channel as well where GCB users and the Cloud Build team discuss features an different use cases. Happy to see anyone on there. https://googlecloud-community.slack.com/messages/C4KCRJL4D/c...

We appreciate all the positive feedback on the thread as well. We're excited about what's ahead for Cloud Build and that it's helping people be more productive!

Awesome to see this product getting more love! I'm looking forward to the Github status updates.

A few suggestions from my experience using the product for the last few months:

- Setting the machine type on a per-step basis instead of for the entire job. For example, I'd like to use a large box to compile my scala, but can use a smaller one to test each package.

- Showing the status of each step before everything ends.

- Showing the elapsed time for a job on the page for the job in addition to the start time.

- Failing a single step without stopping the build (for example, a single project in a ci build fails.)

- Speeding up the web view (it's very frustratingly laggy when you have a significant logs in your build.)

- Using the dataflow visualization for cloud builder.

- JUnit support

Please change your username, which is misleading (makes think you represent Google Cloud Build in some capacity). @dang
Do you even support trivial features like sending an email if a build fails? Please don't answer write your own pubsub component. If you don't have that, you shouldn't have bothered rereleasing this.
It doesn't appear to be a rebranding, but an upgrade or a rewrite, since the site mentions the first two points (that I checked):

https://cloud.google.com/cloud-build/

"Set up triggers to automatically build, test, or deploy source code when you push changes to GitHub, Cloud Source Repositories, or a Bitbucket repository."

https://cloud.google.com/cloud-build/docs/configure-third-pa...

I looked at Container Builder before and, like you, was not impressed, but this is something else.

Container Builder has been able to trigger based on changes to GitHub repos for a while (tags and merges to branches). What it (and the new branding) can't do, and what the parent comment is referring to, is trigger builds when PRs are opened, and update the PR with the build status.
Don't you need an existing branch to open a PR? I get your second point about updating the PR itself: everything needs to go through PubSub.

Edit: I found the changelog (https://cloud.google.com/cloud-build/release-notes), which confirms that this is both a rebranding and update, but also points to a new alpha GitHub app: https://cloud.google.com/cloud-build/docs/run-builds-on-gith...

"Observe that the Google Cloud Build app builds your code on creating a pull request."

"Go to the Checks tab. You'll see that Cloud Build has built your changes and you should see that your build has succeded. You'll also see other build details such as the time it took to build your code, the build ID, etc."

There might be hope...

> Ability to send messages to slack on successful / failed builds

That should be easy enough, request a new cloud builder Slack. Currently this is possible though using the curl cloud builder and constructing a custom curl request to the Slack API.

> No story on how to store secrets

Agree, need a way to mark variables as sensitive/secure. Don't show them in the build history in plain text and make the input field of password type. Encrypt somehow when stored as well.

> Conditional build steps AT ALL

Agree, this is a biggest missing piece.

Encrypted environment variables and file contents are supported using Cloud KMS.
Is there an example/documentation of using a value from KMS in a cloudbuilder.yaml file?
The demo I just saw certainly seemed to have all of those things (except possibly PR status updates and outside integrations). I don't think it's a rebranding but an update.

We've been using https://drone.io/ for some time, which is very, very similar, but if we weren't I'd give it some serious consideration.