Skip to content

A ci command alias auto-derived from workflow steps #202

@armanbilge

Description

@armanbilge

As @djspiewak says:

basically ci isn't needed all that often, but when you do need it, you really need it
at least I've never worked on any long-lived project at any point in my career that didn't, at some point, need it

@rossabaker is this relevant at all e.g. when http4s does a release to patch a CVE? IIRC those are done manually, but is there a reason they can't/aren't done from CI?

Ross also had an idea in #65 (comment) to make ci a task rather than a command.

I pointed out in #65 (comment) that it's difficult/impossible to manipulate an opaque ci command and punted the issue. Early milestones of sbt-typelevel worked like this and it was annoying being unable to add a step to ci without redefining the entire command.

In any case, since the source-of-truth for CI is the workflow, and the plugin knows the workflow, we should be able to derive the ci command automatically. I've definitely thought about this but I'm not sure I have the sbt-fu to pull this off myself 😅

One thing that seems tricky to me is how this would interact with additional CI jobs added to the workflow e.g. as suggested in #93.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions