Use a binary target for the build tool plugin #4603
Conversation
Generated by |
| .binaryTarget( | ||
| name: "SwiftLintBinary", | ||
| url: "https://github.com/realm/SwiftLint/releases/download/0.50.1/SwiftLintBinary-macos.artifactbundle.zip", | ||
| checksum: "487c57b5a39b80d64a20a2d052312c3f5ff1a4ea28e3cf5556e43c5b9a184c0c" |
There was a problem hiding this comment.
There’s a chicken and egg problem here. We won’t know the checksum until after the artifact is created.
There was a problem hiding this comment.
This is very, very correct. I need to do some reading, because this seems like a thing that Apple would have thought of.
SwiftPM probably allows a local binary target at a path within the repository.
There was a problem hiding this comment.
Technically I guess you could build the binary, update this file, tag it, and still add the binary to the release tag even though it was built from 1 commit before the actual tag ¯_(ツ)_/¯
There was a problem hiding this comment.
That's true.
What's the release process look like now? Is it automated?
There was a problem hiding this comment.
Ah yep, I can see the "Releasing.md" file.
I'll propose some updates to the Makefile to calculate the checksum and pipe it into the Package description as part of the release process.
There was a problem hiding this comment.
Okay, I've just pushed a few commits that resolve an infinite recursion bug for filesystems that don't have a configuration, and quietened the output so that Xcode only prints violations, not the checked files.
There was a problem hiding this comment.
There’s a lint failure due to a long line and a build failure on Linux. If you don’t get around to fixing those I can do that later.
There was a problem hiding this comment.
All done, let's see if it passes CI now
There was a problem hiding this comment.
It's your call, but it might be worth cutting a release for that infinite recursion bug that I fixed. That's present in 0.50.1, as well.
There was a problem hiding this comment.
I’ll keep it in mind. Frequent releases means frequent cache invalidations, which impacts all users, not just the ones that would be impacted by this bug.
Instead of running `make push_version "0.2.0: Tumble Dry"` and then `make release`, now run `make release "0.2.0: Tumble Dry"`, which will build the release artifacts and update/push the new version to GitHub. This allows the artifacts to use the new version, update the artifact bundle checksum in the package manifest, then tag the release. The Releasing.md instructions were updated to reflect this new workflow.
This shouldn’t trigger sandbox violations, I hope…
This will save users of the build tool plugin from having to compile the CLI tool before running the plugin.
I'm still having a look at how to automate the updating of the binary details in the Package description.