Automatic builds

[realies]

Will be looking into integrating Jenkins for remote repository monitoring and automatic patching of the master and later the stable branches. It would make sense to automate the building process of the images in Docker Hub based on changes from the GitHub repository. Currently it seems that you manually build and push the images since the Docker Hub repository description, Dockerfile and readme are out of date. Would it possible to resolve automatic builds on Docker Hub?

[stevesbrain]

I can certainly try resolving the auto builds, however, I don't know if Docker provides any actual "logs" as to where/why it's failing. I'll try kicking off some builds again and see whether they succeed (on a new tag). Apologies for the lengthy delay in responding; missed this one in my notifications.

[realies]

Great stuff, will look into automating the latest commit fetching, comparing and patching of Dockerfile for the repositories that the image uses. Currently I do something very similar with the access-watch-docker repository, which follows access-watch and patches the Dockerfile on a change, which then triggers a rebuild on Docker hub. Is this something that you would be happy with for this image?

[stevesbrain]

Yep, definitely happy for that to go ahead :)

[stevesbrain]

Automated build actually finished this time; just testing out now if it works or not (which was the initial problem; resulting image wouldn't actually function).

[stevesbrain]

Follow up - it is all working/building properly now! I've re-enabled the webhook which will trigger master:latest and stable:stable builds on push!

[realies]

Great! Just noticed that the new addition of the Slack plugin does not have anything in its repository releases section (addressed here). All the others look good to be used for the stable branch.

[stevesbrain]

Awesome; once they add those tags, we'll update them for stable then. Be nice if the other projects came out with some releases newer than 2017 😁

[realies]

Starting to be a bit discouraged for the stable branch. Was testing the latest commit of the Slack plugin against 4a9c6b0 of BitlBee and found there was a bug where posting a message from myself within the Slack chat would not reflect the chat log in BitlBee. Consulting a BitlBee developer it turned out that is a bug that was fixed after 4a9c6b0 which I can confirm.

01:56 <realies>  not sure how great the idea of maintaining a `stable` branch for that docker container would be, considering some of the plugins don't work well with older versions of bitlbee
01:58 <dx>  pretty much the same problem with linux distros that keep 'stable' branches
01:59 <dx>  they freeze versions and miss out on both bugs and bugfixes

Can we guarantee compatibility and if not, should there be a stable branch? To be investigated...

[stevesbrain]

Given the slow release cycle upstream, and the relative stability of latest (in that everything appears to work anyway), I'd be more inclined to drop stable and just stick with latest, and perhaps periodically tag our own releases + images with versioning that we keep around (an easy way for people to revert back if latest introduces some bugs)?