Adding working version to repo and new workflow for building and tagging

[thelamer]

For mono to work properly you need GlibC, reference base image here:

https://github.com/frol/docker-alpine-mono

Also, bailed on versioning mono and ffmpeg, the current releases will be pulled dynamically in this.

On to the build system, this adds the concept of the jenkinsfile which will require blueocean installed on the build server:

https://jenkins.io/projects/blueocean/

When commits are pushed to this repo, it will trigger a build and push of the last 10 emby release tags.

When a new release is pushed by emby we can trigger that build using the URL trigger for jenkins in a separate pipeline:

https://wiki.jenkins.io/display/JENKINS/URLTrigger+Plugin

The config looks like this:

And the pipeline config:

node {
   stage('Pull and define tag') {
      git 'https://github.com/linuxserver/docker-emby.git'
      sh '''curl -s https://api.github.com/repos/MediaBrowser/Emby/releases | jq -r '.[] | .tag_name' | head -1 > release.txt'''
   }
   stage('Build') {
     sh 'docker build --no-cache -t linuxserver/emby:$(cat release.txt) --build-arg EMBY_VER=$(cat release.txt) .'
   }
   stage('Push') {
     sh 'docker tag linuxserver/emby:$(cat release.txt) qcom/radarr:latest'
     sh 'docker push linuxserver/emby:latest'
     sh 'docker push linuxserver/emby:$(cat release.txt)'
   }
}

To use this the Jenkins slave will need jq installed : http://manpages.ubuntu.com/manpages/xenial/man1/jq.1.html

[LinuxServer-CI]

Can an admin please whisper to jenkins to test this PR.

[sparklyballs]

this wasn't the best image to have chosen as we're probably never going to release it

plus we don't hack in glibc to alpine like this

[sparklyballs]

closing this as emby is not released and may not be as was just a testbed for ffmpeg static builds

plus we don't like hacking in glibc and if an app needs it we revert to the lsiobase/xenial image