Add automated build

[basil]

I found it quite difficult to get a local build from this repository, even using the instructions in the README and the official Docker image. To make it easier to use the official Docker image, I wrote a little script that sets up the required environment variables and drops you into a shell (or executes your commands, pending jenkinsci/docker-inbound-agent#254), and another little script that does some of the preparatory actions needed before starting a build (downloading the WAR and importing the test GPG key). The result is that it's easy to build this repository now, as long as you have Docker. Just run ./bldenv.sh followed by ./build.sh.

If I had write access to this repository, this PR would also include a Jenkinsfile that runs the build on ci.jenkins.io.

[timja]

You do have write access?

[basil]

I just realized that now. =) I'll play around with a Jenkinsfile.

[basil]

I added a first stab at a Jenkinsfile, but it doesn't seem to be getting run, so I'm guessing a new job needs to be created on ci.jenkins.io.

[basil]

Worked on the first try! Now that's something that's never happened to me with a Jenkins job before.

[dduportal]

Thanks a lot for tackling this!

It's clearly better to have a CI build (than not having any).

It looks like that we could use the existing docker-compose.yaml (https://github.com/jenkinsci/packaging/blob/3ef73d3cca85325b7c9ab7366627370377de61b2/docker-compose.yaml) to provide the same behavior on both CI and developer workstations in a subsequent PR (that would remove the need for shell scripts and would allow contributors on different platforms to work it out).

[timja]

I had to revert the docker-inbound-agent patch as it broke multiple people's builds, could the entrypoint be overridden here instead?

[dduportal]

I had to revert the docker-inbound-agent patch as it broke multiple people's builds, could the entrypoint be overridden here instead?

+1 with overriding the entrypoint instead. The whole issue come from the docker-packaging image that is slowing you down: I wonder if we shouldn't stop using Kubernetes pod agent for this use case, and use VMs with a full Docker engine instead? So the only requirement is "you want to package ? Use Docker CE and follow README". WDYT?

[basil]

I had to revert the docker-inbound-agent patch as it broke multiple people's builds, could the entrypoint be overridden here instead?

bldenv.sh is deleted

[dduportal]

@basil would it be useful for you to have a Docker image "packaging" that would only contain the required package (without the inbound stuff that the infra adds in jenkins-infra/docker-packaging) ?

I wonder if adding a Dockerfile in the repository here, that would define a jenkinsci/packaging (or jenkinsciinfra/packaging:x.y.z-base) , would help?

I'm asking because part of your problem here was caused by us (jenkins infra team) when we changed the image docker-packaging to "inbound agent" and breaking the contract here.

WDYT?

[basil]

WDYT?

Not sure offhand.