Consider archiving in favor of stack-action

[pbrisbin]

Since freckle/stack-action@v4, caching is handled there and we do not need to use this action when also using it. When we did that, we questioned if this action was valuable and decided that, yes, there may be cases where folks only want caching and are running the stack build themselves. For that reason, having this standalone action was still valuable.

I'd like to re-question that and consider archiving again. I think we always knew that the "caching only" use-case was rare, and I've only found one example in our own projects: where a CLI tool uses a make (or just) task to run stack as part of building the release distribution. In this case, we'd like to add caching, but not run any build.

We knew this, but I think the new information for me is that even such cases can be accomplished with stack-action.

Given any step like:

- uses: freckle/stack-cache-action@v2
  with:
    stack-yaml: x
    working-directory: y
    prefix: z

The following should be functionally equivalent:

- uses: freckle/stack-action@v6
  env:
    STACK_YAML: x
  with:
    working-directory: y
    cache-prefix: z
    stack-build-arguments: --dry-run # disables any building
    install-stack: false # avoid other behaviors, if desired
    upgrade-stack: false

I propose we document that in the README, close out all Issues and PRs, and archive.

[pbrisbin]

@mjgpy3 @chris-martin WDYT?

[mjgpy3]

I'm really fine either way.

I like the idea that we provide small building blocks, however, these packages are highly cohesive (to your point, why'd we want just this action?).

I like having fewer repos to maintain but I also like having smaller (i.e. fewer responsibility) repos to maintian.

I guess thinking through this more, all the overhead of a separate repo/buildchain does make it cost more overall. It also makes for more complicated build yamls.

Sure, let's archive.

[pbrisbin]

does make it cost more overall

Yeah, my main reason for raising this now is seeing the Renovate PRs stacking up because we need to do the work to migrate to ESM (and vitest, and typescript 6, and pnpm, and...).

It seems like JavaScript still has a lot of churn in build tooling, so having this lower-value repository around does add meaningful work to keep it up to date with that.

Archiving it, IMO, is just saying that we are going to freeze it where it is in terms of updates and build tooling. Folks can even still use it just fine. And if the bit-rot eventually wins, stack-action is there. 🤷

[pbrisbin]

I came up with a different idea: just make this action a composite that passes through to stack-action: #393

What do we think about that, vs archiving as-is?

[mjgpy3]

I assume making it composite would remove the need for auto-dep-updates? If so, sounds good to me.

[pbrisbin]

Yeah, it should be zero maintenance. Only when stack-action has a major version update.

[pbrisbin]

Downsides I see are:

• We lose the cache-hit output
• It does do some more work (--dry-run isn't nothing)
• It will install GHC

The last point is the only one that stands out, because it does add a lot of time. But if we assume anyone using this action is in fact going to build something somewhere after, that time as just moved from there to here.