Feature request: Instantaneous updates

[Hexstream]

When my issues are reported as fixed on GitHub,
I like to actually check the live site to verify that everything is now as I expect.

Unfortunately, there is a very noticeable delay of at least several hours
between the issue being fixed and the live site reflecting the changes.

This delay prevents me from immediately verifying the fixes and moving on from the issue, which is very annoying.
(I'm sure I'm not the only one who has noticed this and is annoyed with the inefficiency...)

I'm sure there are reasons for this related to the current pipeline (daily build?), but I see no fundamental reason why there couldn't be an incremental rebuild and update system that would translate to instantaneous updates in most cases at least.

Needless to say, accelerating the workflow for everyone would be very nice and productive...

The first step towards fixing this would be documenting all reasons why updates are not already nearly instantaneous...

At the very least, it would be nice to know how to determine the exact time at which we can expect updates to land on the live site.

[fiji-flo]

We're working towards this. Our deploy time peaked at about 1.5hrs and that's the reason we do daily deployments only. Well that's a bad excuse but getting somewhere else is work (which we're doing).

One major piece was moving to rari for our build. We do need a full build (well with a lot work we could do it incremental, but it's probably even slower) because a change of for example a title in document changes generated links in other docs. But well on decent hardware all of MDN now builds in a few seconds (on the current GH workers ~4min).

There's two other pieces to be solved. Versioning the front-end we use for deployment and uploading.

We're working towards this. However there's still the CDN in place and Googles CDN (which we currently use) is not the greatest at invalidation. But we'll get there.

Unfortunately, there's no exact time for when the change land. It's after https://github.com/mdn/yari/actions/workflows/prod-build.yml ran with the changes and then either wait for the CDN to expire (<1h in most cases) or add a search query to break the cache (like: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array?somethingunique)

[Hexstream]

We're working towards this.

Awesome!! 🎉

We do need a full build (well with a lot work we could do it incremental, but it's probably even slower) because a change of for example a title in document changes generated links in other docs.

I don't follow. Given a suitable architecture, tracking these kinds of (reverse-)dependencies is very easy, and would definitely greatly speed up builds to nearly nothing for small changes, the most common occurrence. (Obviously you don't want to incur a full (re)scan of the project just to determine what needs to be built...)

It may be that some special types of changes may require a full rebuild since accurately tracking all (reverse-)dependencies could be too hard (or the change actually impacts all or most pages), but this should be relatively rare. Most types of (especially content) changes are much more pedestrian in nature.

However there's still the CDN in place and Googles CDN (which we currently use) is not the greatest at invalidation.

Cloudflare supports instantaneous invalidation, highly recommended!!

[myfonj]

Have you considered introducing ~ 🏷 waiting for deploy label on open → closed::completed issue transition, that would only be swapped to 🏷 deployed after reasonably "safe" CDN cache invalidation period?

That could possibly repel some FUD for reporters, while still allowing batched deploys.