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.

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

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

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

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
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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants