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
A relatively new option is to use a Docker based development environment https://github.com/Kong/kong-build-tools#developing-kong.
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.
Anything you can share back? 
It’s on my todo list to migrate some of our own plugins so any prior art I can steal is appreciated lol
Hi @hutchic! Yes, sure!
I am new to Kong but I’m here to stay.
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?
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 
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.
What do you think?
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.