Delivery on chef/chef

Looks like someone enabled delivery on the main Chef repo. Can we not do that until we have a better story for non-employees interacting with it? Also maybe until after it can generate emails nicer than http://i.coderanger.net/uEH4J.png?

I think delivery is very likely the path to get us to the place where all maintainers can produce official builds. Also, reduced risk through continuous delivery and all that, sure, but honestly my heart is on the first part. But delivery definitely isn’t ready for our kind of project or workflow. There’s a long ways to go in terms of figuring out how we want to interact with it, as well as internally at Chef figuring out how to connect existing infrastructure.

I started this conversation at the summit in the Delivering Chef with Delivery space. We absolutely need to continue it. There are many unanswered questions about what works, what doesn’t, and how we would need to reshape the product for our use. Let’s keep talking.

I’m not thrilled myself with how delivery uses a comment to display pipeline progress. I don’t have a brilliant alternative yet though. But we really can’t block developers working on underlying build and test frameworks until we figure out the UI. Let’s find a compromise in there for now.

In its current state, delivery doesn’t trust strangers, so it’s not going to talk to them anyway. I doubt many people watch the entire chef repository anyway, I’ve gone back and forth myself. So I’d look at it this way, someone opened a WIP pull request that has a couple comments that you’re not interested in. Can you ignore/mute that one thread like you would any other that you’re not interested in?

I’ve been thinking about how to visualize and discuss all the bits. The chef-dev list/category is good for specific discussions, but I’m thinking about using the etherpad instance over at https://e.chef.io to start jotting down issues and needs so we can let them percolate.

Yeah, I did that: https://e.chef.io/p/chef_client_delivery

Bryan

I agree it could be a thing one day, but for now the UX isn’t viable for using Delivery on Chef. Unfortunately there is no way to ignore the delivery comments that I can see, they are being left directly on commit objects.

Dogfooding is admirable, but this isn’t the time or the place. A large, public, open-source project wasn’t the original design goal from everything I’ve heard. Tradeoffs that make sense for a company-level tool don’t make sense for a public one. If Chef Software is going to put in the hours to add the needed features, then so be it, add them and then we can look again, but I feel like that would be chasing the dragon at best. At a minimum we would need to add anonymous access to Delivery, move the Chef Software instance to a public VM, and add some level of security to prevent rogue builds from being used as an attack vector (yes I know Delivery supports manual-ack-based builds, that isn’t viable IMO for something community-based like Chef).

So I say again, please remove this and we can revisit when the scope of Delivery is extended to include public projects. We can absolutely tell the people working on UX that they shouldn’t do it on a running project that has stuff like new users to deal with. I care waaaaay more about keep Chef welcoming to new contributors than I do about the development process for Delivery, and I don’t see any way to have those two not be in conflict right now.

If you want to look at allowing maintainers to do releases, I would probably recommend building something on top of Travis, as it already provides the features I’ve mentioned.

we cant use travis. travis does not have any notion of pipelines. having agents based on different platforms will ease the release process, travis will not help there.

but i find absurd that Chef pr;s will get badges and the corresponding links are not public. is that acceptable? i dont know, i think it should not be, but i dont know all the reasons.

@btm if the intention is to test/develop delivery projects UI itself, why not create a fork and sync it periodically and configure delivery against it. Using the main repo to develop delivery is gonna hurt the whole community, or atleast annoy those who are watching /reviewing PRs, given the feedback links are private.

@Ranjib One major issue is that Delivery doesn’t have UI access controls AFAIK, so no great way to make it public without a teensey security issue.

  • Someone opened a PR testing unit tests under delivery, it had very minimal impact on anyone else. We all should have slowed waaay down, made less presumptions about what others were expecting, and talked more openly.

  • all delivery webhooks are off for chef/chef

  • our build/test/release pipeline for chef-client is huge and needs to be bigger, existing tools won’t cut it. lets talk more about that later.

1 Like

You should be aware that we have an entirely internal build infrastructure for omnibus-chef artifacts called “manhattan-ci” that does build/test/release on Solaris/FreeBSD/CentOS/AIX/etc that you have zero visibility into. And people can and do cut PRs which fly through the travis testing on Ubuntu and Windows testing on Appveyor, which then turn those builds red and then we wind up fixing it internally.

There’s so many things wrong with that, but we’re really uncomfortable with hanging our jenkins infrastructure that has all the keys to release omnibus-chef outside of the firewall for one.

Delivery for chef-client will ultimately fix all of that, and the end goal has always been to have a publicly-available delivery WebUI that everyone can see the status of builds, and maintainers on the chef project will have full access to promote code through the pipelines. What happened isn’t really ‘absurd’ its just that we’re not ready to ship all of that and people who were working on pushing the whole thing forwards tried to get done what they could get done within the existing framework.

I find it kind of ironic that people are getting upset over efforts to try to make our entirely private build pipeline more public because we didn’t make it land 100% public. The current system we have is the one you should have more concerns about it because nobody but us gets to touch anything related to it. Even in the shape that we were trying to ship chef-on-delivery, would have been a bit better since then you’d actually get feedback when something went red and would be able to at least ping someone for info.

yes it is ironic. on one level that you think that we dont know there exist an in house cross platform CI which we dont have access to (we know, we know who works on it, we have several chats in chef conf, summit regarding that), on another level that you concluded its the CI/CD bits that im finding absurd. It was the updates/public comments on the PRs with private links that i found absurd. I am very happy that there exist an internal CI, and happy that delivery improves that adding more features. The comment was more towards using the main repo to test it, while a clone/fork can do it (this is equivalent to the i test it in production meme). We all definitely wants deliver or something similar on Chef, but i think we dont agree on using the main repo for its development purpose, or to be precise just the bit, that it leave a public comment with an un-accessable link. that was it. you can dark launch delivery. this is not the first project which has such requirements.