Added docker build and quick-start

[mgaffigan]

While this might be somewhat responsive to #40, it is primarily just to provide a quick-start way for a developer to build and test. While trying to address Issue 5 I had hours of challenges getting things building happily - and shifted to docker as an escape hatch.

I do not expect this PR is ready to merge as is, but wanted to get something posted publicly. Known issues include:

• Not responsive to the acceptance criteria listed in Create OIE Docker Image #40
• Uses a personal container registry namespace, rather than https://hub.docker.com/u/openintegrationengine
• I'm not confident that I've implemented vmoptions handling correctly
• Missing examples for docker-compose and playwithdocker

That said, it does work to the point of passing tests, running server, client, and simple message processing.

I'm new to the project, so if I've missed a step please let me know.

[tonygermano]

I updated #40 with how I think the "official" docker container should be implemented. However, I really like the idea of what is presented here to use docker as a developer tool for building and testing.

I've also responded to some of your questions here #2 (comment)

[mgaffigan]

@tonygermano, I'm no longer aware of issues outside of the registry name (presumably someone owns the official URL?).

Differences I'm aware of relative to the original repo:

1. Uses multi-stage build to allow forks and keep dev, test, and prod on the same build pipeline and artifacts
2. Still unclear on jar signing story
3. Omitted tests since they do not seem to run even in the original repo on any modern version of python and need to be reworked. I'm sure there is some version of python, dependencies, and docker that it works - but I've not found it.
4. Publish file is only pushing Temurin JDK on Ubuntu as ${tag}-jdk, and Temurin JRE on Alpine as ${tag} (e.g.: latest-jdk, latest-jre)

Happy to discuss as needed. Every compose file, kubernetes deployment, etc... that I've tested doesn't notice the difference between this and stock.

[tonygermano]

@mgaffigan I pulled your launcher script out of this PR, made significant changes, and put it in its own PR in #119 . I think it is useful outside of a docker context, and it can still be used with docker. Would you mind reviewing it and giving any feedback?

[mgaffigan]

@tonygermano, Excellent! I'd love to see that merged and agree it is useful outside of docker.

[jonbartels]

I think this overlaps with #126 but does not entirely conflict.

This PR creates a builder image and does a good job with doco and pulling in examples. #126 is a release/runtime image. They serve different purposes.

[mgaffigan]

@jonbartels,

Thanks for the review. I think this PR got out of date and looks like it ended up with an accidental merge from #114 at some point. Let me clean it up to minimums. I'll pull the docker-compose examples out as well, assuming they fit better with #126.

[mgaffigan]

I've updated the PR to depend upon #119 for oieserver.sh and match the conventions of #126 assuming that has more community input.

Currently blocked by merge of: #119 and #126

Process used for testing:

1. Check-out this branch
2. Merge Add oieserver launcher script #119, #40 Add initial Dockerfile #126
3. Edit docker/entrypoint.sh to remove cp oieserver_base.vmoptions oieserver.vmoptions
4. docker build -t oie-dev .
5. docker run --rm -p 8443:8443 oie-dev

[kpalang]

I've updated the PR to depend upon #119 for oieserver.sh and match the conventions of #126 assuming that has more community input.

Currently blocked by merge of: #119 and #126

Process used for testing:

1. Check-out this branch

2. Merge [Add oieserver launcher script #119](https://github.com/OpenIntegrationEngine/engine/pull/119), [#40 Add initial Dockerfile #126](https://github.com/OpenIntegrationEngine/engine/pull/126)

3. Edit `docker/entrypoint.sh` to remove `cp oieserver_base.vmoptions oieserver.vmoptions`

4. `docker build -t oie-dev .`

5. `docker run --rm -p 8443:8443 oie-dev`

Don't link to #126, it is still a draft and not ready for review.

[tonygermano]

Neither of these comments are blocking:

1. This does not work in my environment (podman installed from package manager in debian bookworm) because of the COPY --exclude syntax. If I was using docker instead, I think it still would not work without some modification to my environment to tell it to use BuildKit.
2. At some point the content of DEVELOPERS.md will need to be reconciled with the changes to CONTRIBUTING.md in #201 , and likely most of this "how to build" documentation should be moved to https://github.com/OpenIntegrationEngine/docs-website where it can be better organized rather than living in this repo.

[mgaffigan]

@tonygermano

1. This does not work in my environment (podman installed from package manager in debian bookworm) because of the COPY --exclude syntax. If I was using docker instead, I think it still would not work without some modification to my environment to tell it to use BuildKit.

I updated the syntax line to be more specific - hopefully that will give a better error in podman if --exclude is not supported.

2. At some point the content of DEVELOPERS.md will need to be reconciled with the changes to CONTRIBUTING.md in Update CONTRIBUTING.md to enhance build instructions and component-sp… #201 , and likely most of this "how to build" documentation should be moved to https://github.com/OpenIntegrationEngine/docs-website where it can be better organized rather than living in this repo.

Agreed. Updated DEVELOPERS.md to reference the docs website. Not sure about reconciling 201. I wouldn't mind moving that reconciliation to #201, since I'm trying for a small PR here that delivers the dockerfile.

[tonygermano]

I preferred the short and sweet DEVELOPERS.md before Jon's changes. I don't think we're at the point yet to say the docker build is the preferred method. As I mentioned in my previous review, it doesn't work in my environment, and I plan to continue building without docker, but I wasn't going to block others from using it. I also expect the docker build to be slightly slower because it has to copy the source files into the container first and otherwise is running the same build. The local build will definitely be faster if we get incremental builds working eventually.

I think it's good to let the repo have just enough info and refer to the docs site, which can evolve more easily as things change.

[github-actions]

Test Results

  111 files  ±0    214 suites  ±0   7m 3s ⏱️ + 1m 13s
  654 tests ±0    654 ✅ ±0  0 💤 ±0  0 ❌ ±0 
1 308 runs  ±0  1 308 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 5076c0f. ± Comparison against base commit f844f6d.

♻️ This comment has been updated with latest results.

[mgaffigan]

I've removed developers.md entirely to leave that to a separate PR. While we opine about documentation, this PR nears its 1st birthday. Perfect is the enemy of done.

This PR being merged is blocking for smoke testing in github pipelines, and frankly for many modern dev workflows.

[jonbartels]

I have recently worked on Dockerfiles for my own deploys. This update covers updates to the entrypoint script that I have seen in the wild. The new dockerfile seems correct and applies some recent best practices