Continuous integration for plugin repositories

Hello guys, as my plugin grows more and more, I’m looking into adding continuous integration workflow to my repo, notably for linting, testing, building and checking plugin.json.

What tools do you use? Do you have scripts to do so? Is it doable with github actions?

It is possible with github actions. I wrote an article that covers some of it; it might help.

2 Likes

I develop on macOS, and use Travis CI for Linux and Windows. Here’s my config: https://github.com/dhemery/DHE-Modules/blob/6be481c8efb408ae8d2cc66e7a9e680670e3d5a2/.travis.yml

2 Likes

Bruce Frazer has his stuff fairly locked away as far as I can tell and Leonardo too; I’m sure there are others with full build systems.

@Squinky

@modlfo

Since GitHub Actions and Travis CI are already covered, I figured I’d pitch in my CI that uses Microsoft Azure: https://github.com/jatinchowdhury18/ChowDSP-VCV/blob/master/azure-pipelines.yml. Almost all of that script was borrowed from various other devs on here, who could probably explain it better than me.

Not trying to push you towards/away from any particular platforms, but I feel like I should mention that I was using Travis CI for a number of my non-VCV projects until very recently. Travis changed their pricing model in November, so that instead of having unlimited support for open-source projects, they give you an allotment of “credits” that are used up depending on how many minutes your builds run for on different OSes. They have their reasons for making this change, and I can’t fault them for it, but I ended up running out of credits after a couple weeks (Mac builds in particular use up lots of credits). The Travis blogs claim that open-source devs should contact them about recieving specific “open-source” credits, but none of my attempts to contact them have received a response yet. This has been particularly frustrating, since I’ve been using Travis for 5+ years, and have always been more than satisfied with their service and their responsive support.

All of this to say, that I ended up spending most of this weekend migrating a number of my projects to GitHub Actions, which really kept me from enjoying my weekend. I’m sharing this story so hopefully your future weekends are more enjoyable :slight_smile:.

4 Likes

hoho - not me. I have cobbled together build environments for win and linux, and I build on my wife’s mac every now and than. so, nope, I’m

I based mine on the well-written @carbon14 guide above, tweaked it to run on every push so I am aware of any issues before I perform a merge. I use https://github.com/DoozyX/clang-format-lint-action to check formatting with clang-format. I also based my unit testing on @Squinky code and added this to run on the CI, but currently, only the Linux build is tested, as the builds are all cross-compiled on Linux remotely, I want to improve on this when I find time as currently I have to manually run the unit tests on other os’s locally.

If you wish to look at how I combine the above: https://github.com/StudioSixPlusOne/rack-modules/tree/master/.github

1 Like

I have my own server running Jenkins CI together with a few nodes. For the Geodesics Vultiverse I used Github Actions. One linux machine builds for linux and windows. This can be done with the procedure that @carbon14 mentions.

1 Like

Thanks you all for your replies :purple_heart:

I’ll take some time to read it all, and probably a few weekends to port it to my Project!

2 Likes

This conversation inspired me to look at GitHub Actions. I’ve now switched: https://github.com/dhemery/DHE-Modules/blob/2fd7fc3eb622e3aefb681ca7b6dcdd444abc4854/.github/workflows/build-and-test.yml

My setup is delightfully simple. That might mean I’m making unwarranted assumptions about the environment that GitHub Actions provides for each platform. Time will tell.

I’m concerned that the toolchain and make files used by the plugin library are different that what we use (and what I assume this ci env uses). I recently had four ancient plugins all crash the module browser because of that change.

I have the same concerns. If I knew the details of the plugin library build environment, I would definitely try to reproduce that in CI, even if it complicated my CI config.

Well…here you go:

This is the official plugin toolchain used for integration build testing and plugin builds.

2 Likes

Here’s one for Travis CI that builds plugins for all platforms (Windows, Linux and macOS):

I installed in in my local linux. you can find details at the end of this long thread. Tl;DR there is a repo from VCV that let’s you set this up. squinkylabs-plug1 · Issue #388 · VCVRack/library · GitHub

Oh! I see @cschol already posted that. :wink:

1 Like

If you’re interested in azure, you can read this thread Azure Pipelines for Github allows build of plugin which I started nearly 2 years ago now (!!) which has the evolution of people using github. I think what most people do now (and what they discuss at the end of that thread) is pretty far from where I started, but in surge, we have had great experience with github + the free azure tier.

I’m not able to build that (macOS Big Sur 11.1). make docker-build results in a long listing that ends with this:

#16 27.74 llvm-10.0.1.src/test/CodeGen/Thumb2/LowOverheadLoops/vector-unroll.ll
#16 27.74 llvm-10.0.1.src/test/CodeGen/Thumb2/LowOverheadLoops/vmaxmin_vpred_r.mir
#16 27.74 llvm-10.0.1.src/test/CodeGen/Thumb2/LowOverheadLoops/vmldava_in_vpt.mir
#16 27.74 llvm-10.0.1.src/test/CodeGen/Thumb2/LowOverheadLoops/while-negative-offset.mir
#16 27.74 llvm-10.0.1.src/test/CodeGen/Thumb2/LowOverheadLoops/while.mir
#16 27.74 llvm-10.0.1.src/test/CodeGen/Thumb2/LowOverheadLoops/wlstp.mir
#16 27.74 llvm-10.0.1
#16 27.74 [output clipped, log limit 1MiB reached]
#16 29.98 + pushd llvm-10.0.1.src
#16 29.98 + pushd tools
#16 29.98 ++ basename https://github.com/llvm/llvm-project/releases/download/llvmorg-10.0.1/clang-10.0.1.src.tar.xz
#16 29.98 + extract /home/build/rack-plugin-toolchain/osxcross/tarballs/clang-10.0.1.src.tar.xz
#16 29.98 ++ basename /home/build/rack-plugin-toolchain/osxcross/tarballs/clang-10.0.1.src.tar.xz
#16 29.98 + echo 'extracting clang-10.0.1.src.tar.xz ...'
#16 29.98 + local tarflags
#16 29.98 + tarflags=xf
#16 29.98 + test -n 1
#16 29.98 + tarflags+=v
#16 29.98 + case $1 in
#16 29.98 + xz -dc /home/build/rack-plugin-toolchain/osxcross/tarballs/clang-10.0.1.src.tar.xz
#16 29.98 + tar xfv -
#16 32.18 + echo ''
#16 32.18 + '[' -e clang-10.0.1.src ']'
#16 32.18 + mv clang-10.0.1.src clang
#16 32.18 + '[' -e 'cfe*' ']'
#16 32.18 + popd
#16 32.18 + '[' -n 1 ']'
#16 32.18 + build build
#16 32.18 + stage=build
#16 32.18 + mkdir -p build
#16 32.18 + pushd build
#16 32.18 + cmake .. -DCMAKE_INSTALL_PREFIX=/home/build/rack-plugin-toolchain/local -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=OFF -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=1
#16 39.14 /usr/bin/ar: creating t.a
#16 46.51 -- Version: 0.0.0
#16 47.49 -- Performing Test HAVE_GNU_POSIX_REGEX
#16 47.49 -- Performing Test HAVE_GNU_POSIX_REGEX
#16 47.52 -- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
#16 47.52 -- Performing Test HAVE_POSIX_REGEX
#16 47.52 -- Performing Test HAVE_POSIX_REGEX
#16 47.74 -- Performing Test HAVE_POSIX_REGEX -- success
#16 47.74 -- Performing Test HAVE_STEADY_CLOCK
#16 47.74 -- Performing Test HAVE_STEADY_CLOCK
#16 47.88 -- Performing Test HAVE_STEADY_CLOCK -- success
#16 54.90 + make -j 4 VERBOSE=1
#16 207.4 /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/lib/DebugInfo/CodeView/TypeStreamMerger.cpp: In member function 'llvm::ArrayRef<unsigned char> {anonymous}::TypeStreamMerger::remapIndices(const CVType&, llvm::MutableArrayRef<unsigned char>)':
#16 207.4 /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/lib/DebugInfo/CodeView/TypeStreamMerger.cpp:392:12: warning: unused variable 'AlignedSize' [-Wunused-variable]
#16 207.4   392 |   unsigned AlignedSize = alignTo(OriginalType.RecordData.size(), 4);
#16 207.4       |            ^~~~~~~~~~~
#16 280.6 /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/lib/IR/Core.cpp: In function 'void LLVMContextSetDiagnosticHandler(LLVMContextRef, LLVMDiagnosticHandler, void*)':
#16 280.6 /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/lib/IR/Core.cpp:89:18: warning: cast between incompatible function types from 'LLVMDiagnosticHandler' {aka 'void (*)(LLVMOpaqueDiagnosticInfo*, void*)'} to 'llvm::DiagnosticHandler::DiagnosticHandlerTy' {aka 'void (*)(const llvm::DiagnosticInfo&, void*)'} [-Wcast-function-type]
#16 280.6    89 |           Handler),
#16 280.6       |                  ^
#16 280.6 /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/lib/IR/Core.cpp: In function 'void (* LLVMContextGetDiagnosticHandler(LLVMContextRef))(LLVMDiagnosticInfoRef, void*)':
#16 280.6 /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/lib/IR/Core.cpp:95:48: warning: cast between incompatible function types from 'llvm::DiagnosticHandler::DiagnosticHandlerTy' {aka 'void (*)(const llvm::DiagnosticInfo&, void*)'} to 'LLVMDiagnosticHandler' {aka 'void (*)(LLVMOpaqueDiagnosticInfo*, void*)'} [-Wcast-function-type]
#16 280.6    95 |       unwrap(C)->getDiagnosticHandlerCallBack());
#16 280.6       |                                                ^
#16 281.6 In file included from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/include/llvm/ADT/Twine.h:12,
#16 281.6                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/include/llvm/ADT/Triple.h:12,
#16 281.6                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/tools/clang/include/clang/Basic/ObjCRuntime.h:19,
#16 281.6                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/tools/clang/include/clang/Basic/LangOptions.h:19,
#16 281.6                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/tools/clang/include/clang/Lex/Lexer.h:16,
#16 281.6                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/tools/clang/lib/Lex/Lexer.cpp:13:
#16 281.6 /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/include/llvm/ADT/SmallVector.h: In static member function 'static void clang::Lexer::Stringify(llvm::SmallVectorImpl<char>&)':
#16 281.6 /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/include/llvm/ADT/SmallVector.h:491:7: warning: array subscript 1 is outside array bounds of 'char [1]' [-Warray-bounds]
#16 281.6   491 |       ++EltPtr;
#16 281.6       |       ^~
#16 281.6 /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/tools/clang/lib/Lex/Lexer.cpp:246:9: note: while referencing '<anonymous>'
#16 281.6   246 |         Str.insert(Str.begin() + i + 1, 'n');
#16 281.6       |         ^~~
#16 281.6 In file included from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/include/llvm/ADT/Twine.h:12,
#16 281.6                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/include/llvm/ADT/Triple.h:12,
#16 281.6                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/tools/clang/include/clang/Basic/ObjCRuntime.h:19,
#16 281.6                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/tools/clang/include/clang/Basic/LangOptions.h:19,
#16 281.6                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/tools/clang/include/clang/Lex/Lexer.h:16,
#16 281.6                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/tools/clang/lib/Lex/Lexer.cpp:13:
#16 281.6 /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/include/llvm/ADT/SmallVector.h:491:7: warning: array subscript 1 is outside array bounds of 'char [1]' [-Warray-bounds]
#16 281.6   491 |       ++EltPtr;
#16 281.6       |       ^~
#16 281.6 /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/tools/clang/lib/Lex/Lexer.cpp:234:7: note: while referencing '<anonymous>'
#16 281.6   234 |       Str.insert(Str.begin() + i, '\\');
#16 281.6       |       ^~~
#16 328.2 In file included from /usr/include/string.h:495,
#16 328.2                  from /usr/include/c++/9/cstring:42,
#16 328.2                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/include/llvm/ADT/StringRef.h:18,
#16 328.2                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/include/llvm/BinaryFormat/XCOFF.h:16,
#16 328.2                  from /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/lib/MC/XCOFFObjectWriter.cpp:13:
#16 328.2 In function 'char* strncpy(char*, const char*, size_t)',
#16 328.2     inlined from '{anonymous}::Section::Section(const char*, llvm::XCOFF::SectionTypeFlags, bool, {anonymous}::CsectGroups)' at /home/build/rack-plugin-toolchain/osxcross/build/llvm-10.0.1.src/lib/MC/XCOFFObjectWriter.cpp:135:12:
#16 328.2 /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:34: warning: 'char* __builtin_strncpy(char*, const char*, long unsigned int)' specified bound 8 equals destination size [-Wstringop-truncation]
#16 328.2   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
#16 328.2       |          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#16 431.2 c++: fatal error: Killed signal terminated program cc1plus
#16 431.2 compilation terminated.
#16 431.2 make[3]: *** [tools/clang/lib/Parse/CMakeFiles/obj.clangParse.dir/build.make:89: tools/clang/lib/Parse/CMakeFiles/obj.clangParse.dir/ParseDecl.cpp.o] Error 1
#16 431.2 make[2]: *** [CMakeFiles/Makefile2:30011: tools/clang/lib/Parse/CMakeFiles/obj.clangParse.dir/all] Error 2
#16 431.2 make[2]: *** Waiting for unfinished jobs....
#16 462.0 make[1]: *** [Makefile:152: all] Error 2
#16 462.0 + _exit
#16 462.0 + EC=2
#16 462.0 + '[' 2 -ne 0 ']'
#16 462.0 + test -z build_clang.sh
#16 462.0 + echo ''
#16 462.0 + echo 'exiting with abnormal exit code (2)'
#16 462.0 + test -n 1
#16 462.0 + '[' -n '' ']'
#16 462.0 + echo ''
#16 462.0 + test build_clang.sh = build.sh
#16 462.0 make: *** [Makefile:56: /home/build/rack-plugin-toolchain/local/osxcross] Error 1
------
executor failed running [/bin/sh -c make toolchain-mac]: exit code: 2
make: *** [docker-build] Error 1
[~/programming/rack-plugin-toolchain] 2 %                         

I’m pretty sure this is from the RUN make toolchain-mac step.

Before this is a long list of llvm file paths. I don’t know what’s before that because the output is too big for my terminal’s buffer.

A potentially contributing factor: I am not able to build a MacOSX10.13 SDK tar file, because I don’t have macOS 10.13. So I grabbed one from the internet. I have no way to validate it. (I had first tried building a MaxOS11 SDK tar file, but that failed with… I think… the same kind of output.)

Is it possible for you to make the resulting docker image available in a public docker repo? I’m guessing not (copyright reasons?) or you’d have already done it.