Skip to content

Comments

Dockerignore: convert to whitelist#738

Open
alxndrsn wants to merge 32 commits intogetodk:nextfrom
alxndrsn:test-docker-context
Open

Dockerignore: convert to whitelist#738
alxndrsn wants to merge 32 commits intogetodk:nextfrom
alxndrsn:test-docker-context

Conversation

@alxndrsn
Copy link
Contributor

@alxndrsn alxndrsn commented Oct 5, 2024

Update to #361

  • conflicts resolved
  • convert .dockerignore from blacklist-based to whitelist
  • decrease docker build context size significantly (most savings would come from excluding .git dirs)
  • make docker builds less dependent on local state (e.g. local node_modules in submodules)
  • add script for checking docker build context
  • add CI tests to monitor if surprisingly large changes are made to the build context

To check build context locally, run:

./test/check-docker-context.sh --report

To check against previous .dockerignore:

git checkout next -- .dockerignore && ./test/check-docker-context.sh --report

* convert dockerignore from blacklist-based to whitelist
* decrease docker build context size significantly
* make docker builds less dependent on local state (e.g. local node_modules in submodules)
* add script for checking docker build context
* add CI tests to monitor if surprisingly large changes are made to the build context
@alxndrsn alxndrsn force-pushed the test-docker-context branch from bb9f990 to 5699ebe Compare October 5, 2024 08:54
@alxndrsn alxndrsn requested review from matthew-white and removed request for matthew-white October 5, 2024 08:56
@alxndrsn
Copy link
Contributor Author

alxndrsn commented Oct 5, 2024

Unfortunately generating version.txt requires all .git directories to be included in the build context.

@alxndrsn
Copy link
Contributor Author

alxndrsn commented Oct 5, 2024

Currently, .git in published central-service images is a file:

/usr/odk# cat .git
gitdir: ../.git/modules/server

@lognaturel
Copy link
Member

Could we maybe delete it after the build step in the docker file?

@alxndrsn
Copy link
Contributor Author

alxndrsn commented Oct 7, 2024

Could we maybe delete it after the build step in the docker file?

That could be done, but the file itself looks harmless.

@matthew-white matthew-white changed the base branch from master to next October 8, 2024 13:49
@alxndrsn
Copy link
Contributor Author

alxndrsn commented Feb 13, 2025

Current stats

Note that listed context sizes are less in CI. This is demonstrated in #894.

next

[check-docker-context.sh] File count:  5863
[check-docker-context.sh] Total size: 85 MB

this branch

[check-docker-context.sh] File count:  4610
[check-docker-context.sh] Total size: 67 MB

without .git directories

[check-docker-context.sh] File count:  673
[check-docker-context.sh] Total size: 7 MB

@matthew-white
Copy link
Member

@alxndrsn, it looks like you moved test/check-docker-context.sh into its own PR (#894). Does that sound right? I'm in favor of that idea. I don't totally follow the Docker things happening in that script, so it'd probably be better for someone else to review that PR.

What do you think about removing the script from this PR? I should be able to review the .dockerignore file at least.

@alxndrsn
Copy link
Contributor Author

@alxndrsn, it looks like you moved test/check-docker-context.sh into its own PR (#894). Does that sound right?

👍 Currently integral to this PR is checking that the docker context size has not changed significantly. I'll revisit that idea when #894 is merged/rejected, and see how this PR can be simplified.

@alxndrsn
Copy link
Contributor Author

alxndrsn commented Feb 9, 2026

PR updated to only change .dockerignore.

@alxndrsn alxndrsn marked this pull request as ready for review February 9, 2026 11:34
alxndrsn added a commit that referenced this pull request Feb 12, 2026
Copy link
Member

@matthew-white matthew-white left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking very close to me!

In the previous round of review, I was mostly thinking about files that were listed that needn't be listed. This time, I did a scan through the three Central repos for files that weren't listed here but maybe need to be.

Comment on lines +3 to +5
# .git directories required for generating version.txt

!/.git/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we should include .gitignore files as well. Those could conceivably affect what is logged to version.txt (including whether the Git working directory is clean).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, now that I say that, if we're no longer copying all files that are committed to the repo, won't version.txt indicate that the working directory isn't clean?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great question. I'll investigate. Given the importance of version.txt it would be good to have a test that it's created as expected.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think version.txt is affected by changes to the git working tree.

PR at #1660

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which raises the question: should local changes be reflected in version.txt?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think version.txt is affected by changes to the git working tree.

PR at #1660

I know I was the one to approve that PR, but I thought of it more as a general test of version.txt rather than a test of changes to the git working tree. Does test-images.sh make changes to the working tree before generating version.txt? Or is that what #1662 will do?

Which raises the question: should local changes be reflected in version.txt?

I'm not 100% sure that local changes are reflected in version.txt. I think they used to be, but I'm not sure what the current status is. It'd be kind of nice if they were, just because it gives us more information on the build. E.g., if a Sentry report comes in for a version marked -dirty, it could be that the error was due to a user changing the code. I'm not sure it's important enough to block this PR though.

Comment on lines 9 to 16
!/client/.browserslistrc
!/client/.git/
!/client/index.html
!/client/package.json
!/client/package-lock.json
!/client/vite.config.js
!/client/public/
!/client/src/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't include /client/dist/, but is that because those files are built after the ignore step?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's intentional - the client /dist directory should be created inside the build container rather than passed in via the docker context.

With the current configuration, anything in the host machine's client/dist directory can end up in the generated image.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a merge or rebase is in order? I wouldn't expect to see this file in the diff.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should! This PR significantly decreases the number of files in the docker context 🙂

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very exciting to see those numbers go down!

It looks like test-images.sh is no longer in the diff since the latest merge, so I think this comment can be considered resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants