drahnr / cargo-spellcheck

Checks all your documentation for spelling and grammar mistakes with hunspell and a nlprule based checker for grammar

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Broader CI/Docker usage support

ljoonal opened this issue · comments

commented

Is your feature request related to a particular use-case?

The usecase is running cargo-spellcheck in my CI system, which is based on Drone.
I'm using the official rust:latest Docker image to run the step in which I'm trying to get cargo-spellcheck to work.

A clean build attempt of cargo-spellcheck can take over 15 minutes (on hertzner cx21 = 2vCore 4GB RAM) and fail due to dynamic library linking errors which weren't as trivial as just apt-get installing hunspell.

Trying to just download the precompiled release binary also fails due to being linked against a newer GLIBC version I think.
Additionally means that using the slimmer rust:alpine docker image is also out of question because of the GLIBC requirement.

Describe the solution you'd like to implement/see implemented

  1. Make prebuilt releases against x86_64-unknown-linux-musl.

Seemed to work on my system after doing a hacky workaround sudo ln -s /usr/bin/g++ /usr/bin/musl-g++, which was from rust-musl-builder which could be used too most likely for the building

  1. Provide a Docker image for cargo-spellcheck.

While it'd be better for my use case, I think that just providing a musl binary would potentially be more applicable for other possible similar use cases. Though both would be even more awesome than just picking one :)

Describe alternatives you've considered

  • Build against an older GLIBC version
  • Look into if making cargo-spellcheck properly supported by cargo-quickinstall/cargo-binstall would solve the glibc issues
  • Document the solution to the compilation/linking issues in the official rust docker image, and accept waiting for the CI runs to compile cargo-spellcheck

Additional context

Relates to #241

I do have container build envs ready to produce musl artifacts and as a consequence alpine based containers.

Commonly, I'd create a CI pipeline for the base container of your projects CI pipeline. That's what I do.
I don't quite remember how drone CI works though, so that might not be applicable.

Regardless, I think it'd be a good addition and avoid needlessly burnt CPU time, so I'll take a stab at it soon™

commented

I don't quite remember how drone CI works though, so that might not be applicable.

With the docker runner each step just runs commands in the specified docker container, so yes it'd be applicable 😄

Commonly, I'd create a CI pipeline for the base container of your projects CI pipeline.

Yeah, that could be one optimal solution in the end for my specific use case, which I've just not gotten around to.
Doing that would result in the same issues when building that base pipeline container regardless though.
And if that'd be accepted as the solution, it would mean that everyone who wants to use cargo-spellcheck in a Docker container would still need to do the same & re-discover the steps required for getting it to work.

This is non trivial, mostly due to the fact that the musl-gcc wrapper only suppers C but not C++ and some other shenengians, which brought me down the alpine container road, but the resulting build.rs of that crash with sigsegv 11 😵‍💫

Alright, it seems a series of patches is required to rustc, which the packaged alpine has. So it only needs some more CI love for the release pipeline.

@ljoonal please take a peek at 0.12.2 there are musl binaries now :) I didn't test them yet, so be warned

commented

Yep, seems to run successfully on the rust:alpine image 😄
As an additional note, installation via cargo-binstall seemed to also work successfully on the rust:latest images somehow whilst manually downloading/compiling didn't.