Setting up CI for a Kong Plugin project

#1

HI!
I am developing a Kong Plugin and trying to setup Travis CI for it. I followed the following file as a base to my project: https://github.com/Kong/kong-plugin-prometheus/blob/master/.travis.yml

Looks like the https://github.com/Kong/kong-ci is a private repository… why is that? Is there a way of getting access to it or any workaround?

Does anybody have experience developing community plugins and testing through an external CI tool as Travis?

Thank you!

marco

0 Likes

#2

A relatively new option is to use a Docker based development environment https://github.com/Kong/kong-build-tools#developing-kong.

1 Like

#3

Thanks @hutchic. I’ll check this approach.
I tried something like this: https://github.com/kayaman/kong-plugin
What do you think? I was willing to have a sample Travis configuration file within the kong-plugin repository.

0 Likes

#4

@hutchic Thanks a lot for the tip! Docker made things a real lot easier! Thanks

1 Like

#5

Anything you can share back? :slight_smile:

It’s on my todo list to migrate some of our own plugins so any prior art I can steal is appreciated lol

1 Like

#6

Hi @hutchic! Yes, sure!
I am new to Kong but I’m here to stay. :slight_smile:
Hence, I am really interested and excited about any efforts to standardise and create tools to allow building things faster and in a more straightforward way.
I had terrible experience starting the development of a new plugin following the Vagrant way. I didn’t (and still don’t) have deep experience with Vagrant, neither I intend to do, except someone give me a really good reason to dig deeper on it. I prefer Docker and believe the majority of the community would agree with this choice.

0 Likes

#7

@hutchic Yesterday, I spent some time studying two repositories kong-build-tools and kong-plugin. I was wondering about devising something out of both, specialised for plugin development. What do you think?

1 Like

#8

It’s absolutely on my radar and should be achievable to iterated kong-build-tools to be a better plugin development / test harness. Kong-build-tools does already include a copy of kong-plugin so the pieces are starting to fall in place.

So I was curious if you had any personal progress, found some sharp edges or just feedback on ideal workflow :+1:

0 Likes

#9

I definitely would love to help you on that. I started working on some potential solution yesterday. The problem is that I have only about one week experience with Kong ecosystem overall. There is still a lot of ground for me to cover. But I think it’s feasible,

I’m trying to figure out the big picture and pick out only the parts needed to devise a straightforward framework for writing, testing and packaging plugins.
My feeling so far (please correct me if I’m wrong), is that the goalof the kong-build-tools project is to build Kong releases, with some room for customisations. But, it’s too much boilerplate for specifically building only a plugin.

My dream goal is to have a similar project, like kong-plugin-build-tools, lean and clean. Hopefully it could used together with the Kong releases build tools in future, being responsible for building the bundled plugins, in a sense of separation of concerns.

And one day kong-plugin gets retired. :slight_smile:

What do you think?

1 Like

#10

Correct: the original and currently the primary purpose of kong-build-tools is as you said to build Kong releases.

A convenient and not entirely by accident side effect is the docker container immediately before packaging has all prerequisites of being a Kong development environment (and test) environment.

I merged a PR today to utilize docker hub as a cache so the development environment should be super snappy to bootstrap.

1 Like

Running tests in Vagrant - very slow - alternatives?