Setting up CI for a Kong Plugin project

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:

Looks like the 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!


A relatively new option is to use a Docker based development environment

1 Like

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

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

1 Like

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

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.

@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

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:

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

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