Option to pass in git information and skip git dependency

[luke-j]

I would like to run chromatic in a container that does not include git. Are you open to providing CLI flags to provide the required git info rather than using git directly?

Cheers!

[tmeasday]

In theory yes, but the thing is the package does a complex back and forth with our server to find the nearest commit(s) that have an existing chromatic build.

If you have that information already I guess we could let you pass it in, but I'm not sure it's simple to calculate for you, and if you get it wrong things might go a bit haywire..?

[luke-j]

@tmeasday Yeah, I definitely appreciate the back and forth you mentioned - I wonder if there's an opportunity to simplify this git logic? The installed size of git on alpine is almost 19MB - that seems a decently sized dependency for a CLI tool, especially for an image which is 5MB to begin with.

For some context, I'm running the container on GitHub actions, so have some minimal git info, but anything more complex can be computed on the action box itself and passed into the container.

[tmeasday]

I wonder if there's a possibility to use isomorphic-git, which as a 175kb dependency is certainly a lot less hefty than 19MB: https://bundlephobia.com/[email protected]

My intuition is what we need git for is pretty low-key and chances are is well supported by isomorphic-git.

However that would also add that dependency for all users that already have git installed on their CI machines (read: almost all), so I am not quite sure if the tradeoff is worth it. Plus I don't know if re-implementing our git algorithm is something we want to do right now.

As an aside how large is your code base? As an example the .git directory is much larger than 19MB for the chromatic monorepo already, so I'm not totally sure saving 19MB would help at all in our case.

I wonder if there's an opportunity to simplify this git logic?

If you mean avoid the back-and-forth I'm not sure there really is. The main thing we could do differently is doing the calculation on our backend but we currently do not ask for full access to your source code on GitHub, and thus don't have access to the git history. It's something we may reconsider in the future but it comes with its own set of tradeoffs (mainly that customers don't want to give us that access if they help it, which is fair enough).

[kaelig]

We have a similar use-case at Shopify, where we're using BuildKite.

We can provide the commit message, sha, author, branch… as shown here: https://buildkite.com/docs/pipelines/environment-variables#bk-env-vars

Here's some context about our use-case, taken from our internal docs:

By default, Shopify Build will not make the git history available as part of your checkout. Best practice is that build should not depend on the history of the project. This also makes builds faster, especially for large repositories with a lot of history, because less data has to be moved around.

For now, I'm overriding this best practice for the Chromatic step (and run the CI job with a shallow clone), but it's frowned upon (also, GitHub recommends avoiding shallow clones because their caches are less efficient at serving those).

Again from our internal docs, related to giving access to the git history in CI jobs:

Consider this as a last resort; try to rewrite your build commands in a way so they don't depend on history anymore.

---

In a nutshell: git is available to the CLI, but ideally it would function without the need for a .git directory.

Also, right now we're only using Chromatic for its Storybook upload capabilities, not for UI testing.