Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support sub folder reconciliation logic #1068

Open
sambhav opened this issue Nov 14, 2022 · 5 comments · Fixed by #1358
Open

Support sub folder reconciliation logic #1068

sambhav opened this issue Nov 14, 2022 · 5 comments · Fixed by #1358
Assignees
Labels
good first issue Good for newcomers

Comments

@sambhav
Copy link
Contributor

sambhav commented Nov 14, 2022

Currently if a git repository with a sub folder is used, kpack performs a rebuild even if the subfolder contents are not changed at all.

This is problematic for monorepos with lots of changes. We should support such use cases and only build when necessary.

@tylerphelan
Copy link
Contributor

I like it, we would graciously accept a pr!

@tylerphelan tylerphelan added the good first issue Good for newcomers label Nov 16, 2022
@matthewmcnew
Copy link
Collaborator

@samj1912 How would you expect kpack to detect sub directory specific changes?

@sambhav
Copy link
Contributor Author

sambhav commented Nov 17, 2022

I would imagine that the source controller would need to be changed so that it has the latest commit and the latest effective commit and a build to be triggered only if the latest effective commit changes.

The latest commit reconciliation logic would remain as is but we would need to add a new effective commit field that has additional logic which is equivalent to https://stackoverflow.com/questions/12671404/latest-commit-hash-of-subdirectory

@chenbh
Copy link
Contributor

chenbh commented Oct 20, 2023

Note: this subfolder logic should only apply if .spec.source.git.revision is a branch. Since if an Image is configured with a commit hash or tag, I would assume the user wants to build that exact git tree regardless of files changed in the subfolder.

Pedantry corner

I guess it's technically possible for tags to be re-pushed, and one of those re-pushes could have a change affecting the subfolder. But I consider this enough of an edge case to say we shouldn't support it.

@chenbh
Copy link
Contributor

chenbh commented Jan 11, 2024

#1358 caused a memory usage regression and has been reverted in #1476.

@chenbh chenbh reopened this Jan 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants