Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
armanbilge opened this issue Mar 7, 2022 · 5 comments · May be fixed by #210
Open

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

armanbilge opened this issue Mar 7, 2022 · 5 comments · May be fixed by #210
Labels
enhancement help wanted

Comments

@armanbilge
Copy link
Member

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.
@rossabaker
Copy link
Member

CVE releases are done manually so a binary is available in Maven Central before the vulnerability is publicly disclosed.

They are a bit dangerous because it's easy to forget a step, particularly MiMa. I suppose this is why we'd want a ci that is reasonably authentic.

@armanbilge
Copy link
Member Author

What I don't understand is why you can't just do the release from CI in the private fork that's used to work on the issue?

@rossabaker
Copy link
Member

CI doesn't run on the private fork.

@armanbilge
Copy link
Member Author

armanbilge commented Mar 7, 2022 •
edited
Loading

Oh, I didn't realize that. Yeesh, so you really really do need a ci command because otherwise nobody is checking ...

Edit:

To keep information about vulnerabilities secure, integrations, including CI, cannot access temporary private forks.

https://docs.github.com/en/code-security/repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability#creating-a-temporary-private-fork

Yeah, I guess it makes sense.

@armanbilge armanbilge mentioned this issue Mar 9, 2022
Closed
DavidGregory084 added a commit to opencastsoftware/sbt-typelevel that referenced this issue Mar 14, 2022
@DavidGregory084
Add CI command alias derived from the sbt-github-actions matrix, reso…
450c07e 
…lves typelevel#202
@armanbilge armanbilge linked a pull request Mar 14, 2022 that will close this issue
Add CI command alias derived from the sbt-github-actions matrix #210
Open
@armanbilge
Copy link
Member Author

TIL about https://github.com/nektos/act for running GHA workflows locally. It has a Nix-thingy therefore Ross will like it 😝

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement help wanted
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add CI command alias derived from the sbt-github-actions matrix opencastsoftware/sbt-typelevel
2 participants
@rossabaker @armanbilge