ethomson

Saddened to hear this. As a former GitHub employee, Mona was _a thing_. She had a backstory, and obviously a lot of designs. Simon’s initial work had a lot of impact on GitHub’s design and communications philosophy.

Coincidentally, when I moved to the UK, I had arranged for a taxi from the airport that never showed up. But Simon’s did, apparently. I sat there at a coffeeshop and stared at a taxi driver with a sign for Simon Oxley for a jetlagged hour or so while I waited for mine. I had hoped to catch him for a chat but apparently missed the connection.

More recently, we chatted about one of his designs that I adored and I had asked him about using it for an open source project that I had in mind. He graciously offered me to use it for noncommercial purposes. I got busy with, well, life, and didn’t pursue that. I’m feeling now like I should dust it off and see if it’s useful.

Godspeed, Simon.

Thanks for everything, Cliff. I discovered _The Cuckoo’s Egg_ as a child, and was taken in. I wrote a book report on it... and then I wrote a book report on it the next year... and the next year...

At some point, I stopped trying to drag my pre-teen schoolmates along with me, but I still have my original hardback and re-read it regularly.

Your book taught me many things - perhaps most importantly, that one can educate about complex topics in engaging and understandable ways. And now I’ve landed in a job that focused on security.

One of the things that I’ve been doing in this job is, well, trying to educate about complex topics in engaging and understandable ways. I’ve thought about your book in every blog post I’ve written lately.

Thanks, again.

This is delightful and I can't wait to try it out. Right now, the libgit2 project (https://github.com/libgit2/libgit2) has a custom HTTP git server wrapper that will throttle the responses down to a very slow rate. It's fun watching a `git clone` running over 2400 baud modem speeds, but it's actually been incredibly helpful for testing timeouts, odd buffering problems, and other things that crop up in weird network environments.

I'd love to jettison our hacky custom code and use something off-the-shelf instead.

Yes, that’s definitely the Copper Kettle.

More interesting than the food, though, is the background. Those who aren’t familiar with Cambridge will see King’s College in the background, across the street, which many may know from the BBC’s Carols from King’s.

There’s no confusion about it referring to a dwelling. The confusion is about the _type_ of dwelling.

To quote Wikipedia:

> In American English, "cottage" is one term for such holiday homes, although they may also be called a "cabin", "chalet", or even "camp".

In other words, calling a multi-million pound property a “cottage” would rankle an American ear.

Product Manager for Vercel's storage products here. Today we announced three new storage products in beta; they're based on infrastructure that are provided by partners. There's a lot that goes in to pricing products -- and our products are distinct from our partners' products. We have different roadmaps and will introduce different features as we continue development. So I don't love to make too many comparisons between apples and oranges.

But I suspect that you might be comparing Upstash's per-command pricing for _regional_ requests ($0.20 per 100k) to Vercel KV's? In fact, Vercel KV is multi-region, so the more apt comparison is Upstash's pricing for _global_ requests ($0.40 per 100k).

I was fortunate enough to go in 2019, pre-covid, while I had a day off in Seattle. It was a great museum, and I’m disappointed that I won’t be able to go back.

I tweeted a bunch of photos: https://twitter.com/ethomson/status/1109880552360951810

No - your local server will still listen for webhooks, but they'll come from the proxy's client software.

Basically, you set up your GitHub webhook URL as the proxy server (for example, smee.io). Then you run a client on your local machine that connects to the proxy server. When a webhook is fired, it will be sent to the proxy, then delivered to the connected client, which will then pass it along as a webhook to whatever machine you've configured.

There's disadvantages to having all this stuff running, of course, so I think that handling this at the networking layer instead of putting a proxy just for webhooks into place is an interesting strategy. Certainly, it sounds like the right solution if you're already using OpenZiti.

Neat stuff - certainly this problem crops up quite a lot where an internal server needs to get GitHub webhook data.

In the past, I've had good luck using a webhook proxy. I've mostly just used https://smee.io/ which is simple and lightweight although seems to be mostly abandonware at this point. I dockerized it so that it could be used in a Kubernetes cluster, which was very useful for my GitHub Actions build cluster: https://github.com/ethomson/smee-client

There's also Hookdeck, which I haven't used in production, but have played around with, and it seems conceptually the same, but can be made more Enterprisey. Whether that's a bug or a feature is probably up to you.

Thanks. The "commit and hope for the best" problem really resonates with me. There are two great projects that might provide some pain relief - nektos/act or rhysd/actionlint. But I agree that commit-to-validate is probably the best strategy at the moment, which is deeply unfortunate. This is an area that I intend to improve in the future.

As for the cache, we doubled it at the end of last year to 10GB. https://github.blog/changelog/2021-11-23-github-actions-cach..., but I can see how multi-arch images would be very large. Have you considered putting images into GitHub Container Registry instead of putting the layers into the cache? I'd love to understand if that is appropriate for your workflow, and if not, what the limitation there is.

Appreciate the rest of the feedback, I'll pass it along to the appropriate teams.

Thanks for the feedback! I'm one of the PMs for GitHub Actions, and I appreciate this. Thinking about Actions as a set of primitives that you can compose is very much how I think about the product (and I think the other PMs as well) so I'm glad that resonates.

We're always welcome to feedback, and we're continuing to invest and improve on the product, so I'm hopeful that we can address the features that you're missing.

That's probably not what you want. Checking out an ID would put you in a detached HEAD state, and the CLI will give you the page of warning messages that go along with it. I think that this is an excellent reminder that yes, the git CLI is not simple or obvious.

GitHub turns off rename detection and turns off recursive base-building when creating merge commits in pull requests. Both of these selections would cause differences in when a merge produces conflicts. This is for backward compatibility with historical mechanisms for merging pull requests, but it seems like something that we might want to revisit.

That's certainly possible, but libgit2 carries an _exhaustive_ test corpus around merge as we aim to be bug-for-bug compatible with git-merge-recursive. This was also proved out by A/B testing the two at scale: https://github.blog/2015-12-15-move-fast/

tl;dr: this is a MSCCI plug-in for git, for compatibility with (quite) old versions of Visual Studio.

This is impressive work. I've used the MSCCI API on several projects - MSCCI is the old version control interface for Visual Studio.

MSCCI is the "Microsoft Source Code Control Interface" and was built to integrate Microsoft Visual SourceSafe into Visual Studio. This was because VSS had a checkout/edit/checkin model by default, so files needed to be explicitly checked out from the server (and were locked) so that they could be modified. MSCCI allowed you to paper over this - as soon as you started typing in the editor, you'd get a MSCCI event and you could do the check out.

Unfortunately, the API is really focused on VSS integration. Trying to bring another version control system into this API is... painful. This was - always - the worst part of the UI to work on in SourceOffSite and Vault.

Thankfully, more modern versions of Visual Studio dropped MSCCI (by "more modern" I mean 2005 - adding Team Foundation Server integration to Visual Studio meant that MSCCI was finally deprecated and a new API was added).

However, legacy development projects exist for older Microsoft platforms and using older Visual Studio versions. So I'm both surprised to see that this exists, and am rather heartened by its existence. (But I still feel sorry for anybody who has to use it.)

    frood: noun
    
    (in dogs) a thickly furred section between the forelegs, covering the upper upper surface of the hind legs; a hindleg
    "a ferret with an astonishing, yet brief, frood"

Douglas Adams is rolling over in his grave.

Right, but when you write C, C++ and Swift directly you can also make a program that _doesn't_ leak memory. The question posed was whether that's even possible in Ć?

Product Manager for npm here. That was correct. As part of our integration, we were not excluding withdrawn advisories. We've since corrected this. Apologies!

No, there's no reason why that isn't available. This is a very sensible request and we'll add this information to the context available to workflow runs.

> Sometimes the checkout action fetches the wrong commit!

I'm a product manager at GitHub, and I'm investigating this now. Feel free to drop me an email ([email protected]) if you can share more information about the workflow runs that were affected by this.

> Using autoscaling self hosted runners, it is not currently possible to instruct the agent to finalise the current job but to accept none after it.

We're building this functionality out right now, so that you can have self-hosted runners that will run a single job and we will let you subscribe to webhooks that will let you scale up/down your fleet of runners.

Product Manager at GitHub here - I'll be the Product Manager for npm when the acquisition closes. I agree - npm is definitely an integral part of the JavaScript ecosystem. The npm package registry will remain free for public projects. We're going to work to ensure that the service is stable and accessible, and ready to serve the next million packages.

This is independent of what Microsoft's doing with .NET Core. I'm excited about the work that they're doing, but this isn't going to stop us from making sure that npm is outstanding.

Yes, I love those. We'll keep those around for sure.

Yes, I apologize for not being clear: our Linux virtual machines only run Ubuntu. (We also offer macOS and Windows virtual machines.)

Here's an example: https://www.edwardthomson.com/blog/github_actions_5_building...

Product Manager for GitHub Actions here. You can self-host the GitHub Actions runners. This means that you can run CI/CD workflows on your own hardware, while your source code is hosted on github.com itself. https://help.github.com/en/actions/automating-your-workflow-...

The best place to report issues or request features is https://github.community/. The Product and Support teams both visit that regularly.

PM for GitHub Actions here. I wouldn't suggest that you build an action to run a build within a container. We offer container support for workflow runs which should be suitable for this. (Either by specifying the `jobs.<job-id>.container` or by using `docker run ...`)

Actions themselves are meant to support the workflow and distill a set of complex steps into something that can be done in a single workflow command. (For example, download and set up a new version of a Java JDK.) They're meant to be used as steps in many peoples workflows, instead of executing a single workflow.

The actions themselves can be built as either a container, which is self-contained, or as JavaScript. I often recommend the latter, since that will work cross platform (containers only work for people who are using workflows running on Linux).