Add custom CI override functionality

[orloffv]

Add functionality to override isCI variable for custom CI environments.

[gkampitakis]

Hey 👋 Thanks a lot for the pr. I believe what you try to achieve is already supported by the library without having to expose a new method just for this.

snaps := snaps.WithConfig(snaps.Update(os. Getenv("CUSTOM_CI") == "enabled"))

snaps.MatchSnapshot(t, "conditionally update")

And you can have your own logic for NOT updating a snapshot, of course in the case of detecting running on a CI still this won't be overriden.

https://github.com/gkampitakis/go-snaps/blob/main/snaps/utils.go#L117-L127

[orloffv]

Yes, you're right, but I want to cover this case

go-snaps/snaps/matchSnapshot.go

Line 66 in 560fde0

if isCI {

[gkampitakis]

🤔 interesting point let me think about it.

[orloffv]

@gkampitakis what do you think?

[gkampitakis]

Hey I am sorry for the delay. Didn't have time to look at it. Just for context I am skeptical adding one more "knob" there but your use case is legit. Wondering could you set on your env CI=true? This would have the same results.

[orloffv]

Hi @gkampitakis, thanks for getting back to this and considering the use case! 🙌

Setting CI=true in the environment is indeed a valid workaround for some scenarios, but it doesn’t fully address our needs. The core issue is that in our CI pipeline, we don’t have the flexibility to modify environment variables dynamically or override the CI variable due to pipeline constraints. Our CI system runs in a strict and consistent environment without allowing custom variables like CUSTOM_CI.

The purpose of this PR is to provide a lightweight and explicit way to handle these cases, especially for developers who encounter similar limitations. It also avoids tightly coupling custom behavior to the global CI variable, which might be risky if different tools interpret it differently.

That said, I understand the concern about introducing more “knobs.” Would you be open to further discussing how we could make this functionality less intrusive? For example:
• We could introduce it under an experimental flag.
• Or maybe add detailed documentation to clarify when and why to use it?

Looking forward to hearing your thoughts! 😊

[gkampitakis]

@orloffv Thanks for your patience!! So I am inclined to say that this would be the correct solution.

- if isCI {
+ if !shouldUpdate(c.update) {
	handleError(t, err)
	return
}

• Doesn't mess with the globals, it can create weird race conditions
  e.g.

func TestAnother(t *testing.T) {
	t.Parallel()
	snaps.MatchJSON(t, ``)
}

func TestJSON(t *testing.T) {
	t.Parallel()

	snaps.SetCustomCI(true)
....

• Also gives more flexibility how you can update this value.
• Doesn't introduce a new config

Technically when you are creating a snapshot you are updating to have a value.

The only difference with your proposed change is that you will need to update your call to snapshots to something like this.

s := snaps.WithConfig(snaps.Update(false))
s.MatchSnapshot(t, "")

Would this be acceptable solution for you?

[orloffv]

@gkampitakis That’s better!
Will you create the pull request, or should I?

[gkampitakis]

Will work on it asap 👍 Shouldn't take long!