Bump unidata/tomcat-docker from 1a5fb1b to 3f8ba8c

[dependabot]

Bumps unidata/tomcat-docker from 1a5fb1b to 3f8ba8c.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[kwilcox]

@julienchastang The unidata/tomcat images changed a few days ago but I don't see any changes to https://github.com/Unidata/tomcat-docker. How can I audit the changes?

[julienchastang]

I have to regularly update that container to take into account security "Common Vulnerabilities and Exposures" (CVEs). Note that the parent container (e.g., FROM tomcat:8.5-jdk8-openjdk). Has exactly the same issue. DockerHub autobuilds based on parent container triggers may be a solution for you. Or GitHub actions which I have to familiarize myself with, as well.

[kwilcox]

Thanks @julienchastang , I assumed that was the case but wanted to double check. Do you have auto-builds setup through DockerHub?

@abkfenris Implemented a nice pin-to-hash setup for this repository that creates a PR each time the base image changes, that might help you control the build process a little more if that is something you are interested in! #18 and #19.

[abkfenris]

@julienchastang Here are a summary of the changes that I've done to make the docker-erddap builds more reproducible. It took a little bit to figure out the exact setup hence the multiple PRs.

• In Pin the underlying Tomcat image by hash to increase reproducability. #18 I changed our Dockerfile to pin the underlying unidata image.
• In Use Dependabot to check that the base image is up to date #19 I added Dependabot to keep the pinned image up to date, and a GitHub Actions workflow to run on pushes, and manual triggers (workflow dispatch) (and later added PRs in Check daily for new ERDDAP versions #21), to build the image and run a smoke test to make sure Apache can launch ERDDAP in a reasonable amount of time.
  • I also tried to have it push to latest when the commit lands on the master branch, but the action that I was using to cache Docker images between GitHub Actions jobs currently doesn't work with sha.
• It Use Buildx in Github Actions #20 I changed the GitHub Actions workflow to use the new Docker buildx tool which can be more explicit about caching destinations.

[julienchastang]

I just glanced at this, but GitHub actions seems to be the right approach and one that I plan on diving into myself. Yes, currently, I rely on DockerHub for triggered builds for THREDDS and RAMADDA. Though note that I cannot trigger on the official tomcat parent container. DockerHub does not allow it (probably results in too many builds). Again, GitHub actions probably provides a solution here.

[abkfenris]

I can take a swing at a PR if you'd like.