Use go-chef for image builds #989
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bayandin
reviewed
Jun 25, 2024
Omrigan
reviewed
Jul 6, 2024
There was a problem hiding this comment.
The main thing I am concerned here is the status of go-chef going forward. Who is going to be the owner of it? Maybe @neondatabase/developer-productivity? Do we want it to use for other go-based images?
That's unfortunate that there is no standard way of solving this problem in the go community.
sharnoff
force-pushed
the
sharnoff/go-chef
branch
from
b6a3945 to
5646785
Compare
![orca-security-us[bot]](https://avatars.githubusercontent.com/in/276250?s=60&v=4){kind=small}
There was a problem hiding this comment.
Orca Security Scan Summary
| Status | Check | Issues by priority | |
|---|---|---|---|
 Passed |
Infrastructure as Code |  0  0  0  0 |
View in Orca |
| Passed |
Secrets | 0 0 0 0 |
View in Orca |
| Passed |
Vulnerabilities | 0 0 0 0 |
View in Orca |
sharnoff
force-pushed
the
sharnoff/go-chef
branch
from
5646785 to
a10dc14
Compare
It *dramatically* reduces the amount of time it takes to re-run image building if the set of packages used hasn't changed. It's hard to get an objective measurement (because we do get *some* caching from being careful what we add), but: On my machine, for a rebuild after a change in 'pkg/api', it reduces `make docker-build` time from 249s -> 22s. And, it also slightly improves the time it takes to run a clean build. After `docker system prune -af`, it reduces `make docker-build` on my machine from 345s -> 126s.
sharnoff
force-pushed
the
sharnoff/go-chef
branch
from
e063644 to
846575d
Compare
sharnoff
added a commit
that referenced
this pull request
Sep 12, 2024
sharnoff
added a commit
that referenced
this pull request
Sep 12, 2024
sharnoff
added a commit
that referenced
this pull request
Dec 3, 2024
Probably an inadvertent merge conflict between #1090 and #989 meaning we accidentally weren't using go-chef for neonvm-daemon. Noticed this while developing locally and saw that it was re-downloading all of the dependencies for neonvm-daemon every time, even though I was making changes in the scheduler and the dependencies hadn't changed.
sharnoff
added a commit
that referenced
this pull request
Dec 3, 2024
Probably an inadvertent merge conflict between #1090 and #989 meaning we accidentally weren't using go-chef for neonvm-daemon. Noticed this while developing locally and saw that it was re-downloading all of the dependencies for neonvm-daemon every time, even though I was making changes in the scheduler and the dependencies hadn't changed.
sharnoff
added a commit
that referenced
this pull request
Dec 4, 2024
Probably an inadvertent merge conflict between #1090 and #989 meaning we accidentally weren't using go-chef for neonvm-daemon. Noticed this while working on #1163 locally and saw that it was re-downloading all of the dependencies for neonvm-daemon every time, even though I was making changes in the scheduler and the dependencies hadn't changed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It dramatically reduces the amount of time it takes to re-run image building if the set of packages used hasn't changed. It's hard to get an objective measurement (because we do get some caching from being careful what we add), but:
On my machine, for a rebuild after a change in 'pkg/api', it reduces
make docker-buildtime from 249s -> 22s.And, it also slightly improves the time it takes to run a clean build. After
docker system prune -af, it reducesmake docker-buildon my machine from 345s -> 126s.