Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Improved prePR #729
base: main
Are you sure you want to change the base?
Improved prePR #729
Changes from all commits
aa53636
50ed58d
665041a
2182158
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly curious, why did you introduce this setting in the kernel plugin? I think we could introduce and set the default in the CI plugin, without need a blank default.
Also the doc can be more specific that these are the steps run by the
prePR
command alias.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added it to kernel because at my work we are using the Github plugin without using
TypelevelCiPlugin
, so for our use it made more sense to push it into Kernel. Maybe there is an argument that we should be extendingTypelevelCiPlugin
... Ill take a look next week, but now that I
ve looked closer at the CIPlugin it might make sense.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you are only using the kernel plugin, then it's fairly straightforward to do whatever you want directly with
tlCommandAliases
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it is, and I did... I thought I would basically push back up the changes I was making for myself internally. My thought process was that as people add different 'linters' or other things that are expected to pass in CI, such as scalafix/fmt, mima, or sbt-explicit-dependency, or sbt-missinglink , I wanted an easy way to aggregate those into a check at the the same time (in the same auto-plugin) as i was adding the github workflow.
What ended up happening in my world is people started defining a command alias called 'build' in each project and just put in the various steps, but somehow it would always be out of sync with what we actually did in CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, so the reason I'd prefer to keep prePR in kernel is because we have our own custom ci steps and we'd like the easier to extend prePR.