Add ids to workflow steps

[armanbilge]

This is part of the effort to provide a stable API. Some projects need to filter or otherwise identify steps in the workflow. But I'd also like to retain the freedom to change the exact commands that are used in these steps in patch releases (e.g., we may want to define and use a new command alias that keeps the step semantically equivalent but fixes/optimizes some issue).

I'll follow-up with some documentation explaining that the step ids will be stable, but the other contents of the step should not be relied upon.

[rossabaker]

Those steps as stable are starting to remind me of Maven phases, for better and worse.

Is this a firm commitment to keep the multiple steps, and pay the SBT startup cost between them?

[armanbilge]

Is this a firm commitment to keep the multiple steps, and pay the SBT startup cost between them?

Yes, I suppose it is 🤔 I liked this model specifically because it supports this sort of introspection. But I'm open to other ideas about this.

To help mitigate the sbt startup cost while supporting introspection, perhaps we could implement an "optimizing compiler" (optionally enabled/disabled) that attempts to combine consecutive sbt steps in the workflow into a single workflow step. Edit: actually, this seems impossible to do while guarantee correctness, since sbt is stateful.

[armanbilge]

Eh, scratch this PR. A more typeful approach would be to define a List[WorkflowStep] setting for each step. Then, users can easily prepend/append around this step or completely remove it by setting to Nil. This seems better.

[armanbilge]

I think #275 probably supersedes this PR. It provides a way to easily remove certain steps from CI without baking in the assumption that we will "keep the multiple steps, and pay the SBT startup cost between them".

In any case this is an old PR, and probably not happening.