-
Notifications
You must be signed in to change notification settings - Fork 32
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
Abort commit if files are modified #11
Comments
Perhaps starting at the DSL we want and then extrapolating back might be useful here? #if canImport(PackageConfig)
import PackageConfig
let config = PackageConfig([
"komondor": [
"pre-push": "swift test",
"pre-commit": [
.expectUnchanged([
"swift run swiftformat .",
"swift run swiftlint autocorrect --path Injectable/",
]),
"git add .",
],
],
])
#endif This is all Swift - so I think this could work? A string could always represent a cmd to execute but enums could wrap with a context (like Then it's a matter of looping through, seeing if it's a string or a special case? |
Much more extensible and flexible 👍 Seems like the way to go! |
Okay hit the first roadblock investigating this path. It seems that you cannot reference the package code from the Which I guess makes sense as the You can try this to reproduce // swift-tools-version:4.2
import PackageDescription
let package = Package(
name: "Komondor",
products: [
.executable(name: "komondor", targets: ["Komondor"]),
],
dependencies: [
// User deps
.package(url: "https://github.com/orta/PackageConfig.git", from: "0.0.1"),
.package(url: "https://github.com/JohnSundell/ShellOut.git", from: "2.1.0"),
// Dev deps
.package(url: "https://github.com/nicklockwood/SwiftFormat.git", from: "0.35.8"), // dev
.package(url: "https://github.com/Realm/SwiftLint.git", from: "0.28.1"), // dev
.package(url: "https://github.com/f-meloni/Rocket", from: "0.1.0"), // dev
],
targets: [
.target(
name: "Komondor",
dependencies: ["PackageConfig", "ShellOut"]
),
.testTarget(
name: "KomondorTests",
dependencies: ["Komondor"]
),
]
)
#if canImport(PackageConfig) && canImport(Komondor)
import PackageConfig
import Komondor
//This is a public function in Komondor
renderScriptHeader("test")
let config = PackageConfig([
"komondor": [
"pre-push": "swift test",
"pre-commit": [
"swift test",
"swift run swiftFormat .",
"swift run swiftlint autocorrect --path Sources/",
"git add .",
],
],
"rocket": [
"after": [
"push",
],
],
])
#endif This will produce the following error.
Maybe I am just doing something wrong, but assuming not should we have yet another package that defines |
Oh yeah, that's a really good point! I had thought about this for packageconfg but not tried implementation anything shibapm/PackageConfig#1 I think that might be really tricky (how would we be sure it was already built and in a linkable state?) to do. Maybe then it'd just have to be special strings :-/ |
IMO after seeing what could be possible mixing in "special strings" doesn't seem like a very nice solution, but it might be the only reasonable way. I did some hacking to see how it might look with an enum to denote command types. I like it. I also had a crack at what a more strictly typed config might look like here Still it is not coming together for me, due to linking issues. I thought it could be solved by using a seperate package but unfortunately it is still failing to resolve stuff. <unknown>:0: error: fatal error encountered during compilation; please file a bug report with your project and the crash log
<unknown>:0: note: Program used external function '_$S16KomondorCommands16CommandProvidingMp' which could not be resolved! It was fun but I have gone past the point of diminishing returns on this one, so I am going to stick with the original approach for now. Thanks for your time! |
It was mentioned here that it might be worth while considering if aborting a commit on file modification during a pre-commit hook could be incorporated directly into Komondor.
I had a look into the code to think about how this might be integrated and at once realised there was many different ways to tackle the problem.
hookOptions
type dictionary, this could allow for additional options to be specifiedconfig
for additional hook configurationconfig["\(hook)-option"]
The following demonstrates a possible way to add staged file modification for pre-commit hook only with out any opt in/out.
I played around a bit with the different options mentioned above but I always felt a little dirty like I was adding something too specific to what is currently a very generic.
Do you have any thoughts on how this might be implemented?
The text was updated successfully, but these errors were encountered: