Overridable revision fetching

[vitch]

What Changed & Why

Based on conversation in #121, this PR introduces an alternative approach to allowing consumers to optimise list operations on S3. I'm currently integrating it in to our monorepo but thought I'd chuck this up for feedback first...

Related issues

#121 The changes from #123 are also shown on this branch but should be reviewed separately over there (not sure how to point a GH PR at a branch on a fork without it trying to merge into that fork?)

PR Checklist

• [ ] Add tests (I can do this later if we think this is a good direction)
• [x] Add documentation
• [x] Prefix documentation-only commits with [DOC]

People

All maintainers

[lukemelia]

I like it. Let's see if it solves your problem well, and then we can move ahead with this if so.

[vitch]

We've been running this branch for a while now and have seen the following:

• Average deploy time down to 6.1 minutes from 10.3 minutes (for apps with a lot of history this is even more extreme!)
• Average activation time down from 7.3 minutes to 2.1 minutes (again, depending on the amount of history for the app)

With the following config:

{
  fetchInitialRevisionsFunc(/* context */) {
    return () => ({ initialRevisions: [] });
  },
  fetchRevisionsFunc(/* context */) {
    return () => ({ revisions: [] });
  },
}

We already stored a separate audit log entry in s3 which we are able to grab in order to solve the "what was the previously activated revision" use case.

We apply the config above based on an environment variable and only set that variable when calling ember deploy or ember deploy:activate from CI (so that ember deploy:list still works).

Given the results above I'll try to add some tests to this branch and aim for it to be mergeable?

[lukemelia]

Sounds good. Thanks for the update @vitch, and glad it is performing well for you!