-
Notifications
You must be signed in to change notification settings - Fork 207
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
tool(dev): update dev container, makefile, remove object files #609
Conversation
90bf985
to
041eebb
Compare
hmm pretty sure we needed those empty object files, so the linter doesn't complain 🤔 |
0f5a249
to
1418ed7
Compare
curl -sL https://apt.llvm.org/llvm.sh | sudo bash -s "$LLVM_VERSION" | ||
echo 'export PATH=$PATH:/usr/lib/llvm-14/bin' >> ~/.profile |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this differs from how we install llvm in the bulid containers, should we make them consistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should the devcontainer be the same base mariner image as the build container?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm im actually not too familiar with the pros and cons, i was thinking jammy would be more known and easy to develop on, but i dont have much experience with mariner. I can update this if you think it is better, then we can be more consistent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the closer the dev / prod impedence match is, the more likely you are to catch compatibility issues. I'd say go with mariner if it's usable in dev.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did mess around for a little bit with this image, seems that some devcontainer features (docker-in-docker, kind, kubernetes-cli, and github-cli) don't work by default so we would have to set that up
Im not sure if it's worth it to figure out the configuration for the above missing features
If you guys think it's worth it then i can play around with it a bit more and figure something out
In this current setup, there is docker-in-docker and kind which works -> if we were to use mariner im not sure if this would work - im thinking it would need to mount to a socket?
I was just envisioning it as installing dependencies, running out make commands that generate retina images, and deploying to kind cluster, so i don't see as much importance in matching this container image with the retina container image
hack/tools/tools.go
Outdated
@@ -13,7 +13,6 @@ $ go install ... | |||
package tools | |||
|
|||
import ( | |||
_ "github.com/golangci/golangci-lint/cmd/golangci-lint" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh i see the makefile changes now. not convinced that that's better, though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reverted and updated to match golangci-lint versions and updated workflow/config - this seemed to solve the issue
@@ -524,6 +524,24 @@ quick-build: | |||
$(MAKE) retina-image PLATFORM=linux/amd64 BUILDX_ACTION=--push | |||
$(MAKE) retina-operator-image PLATFORM=linux/amd64 BUILDX_ACTION=--push | |||
|
|||
.PHONY: quick-build-devcontainer | |||
quick-build-devcontainer: # buildx push doesnt work for some reason in kind |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of *-devcontainer
targets, maybe we could have a REGISTRY=local
flag or something like that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i had these separate to not affect existing commands, and some of the steps here are pretty much tied to devcontainer (like the registry:port)
I can update these though if you think it is better
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i prefer some kind of flag/option rather than duplicate targets if everything else is identical, but i guess that can be less discoverable also. no strong opinion, your call
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My preference is for dev-related things to have a fast alias and prod-build things to have more flags and knobs. Yes, there's always shell aliases, but it is nice when the standard dev experience doesn't require creating aliases to be productive. It's easy to put whatever flags / tuning are needed in CI, so I'm not as bothered by that (and +1 to the discoverability problem for devex).
3df6854
to
41a9d4c
Compare
220fb4b
to
7e7cbd2
Compare
d22a563
to
50148ec
Compare
50148ec
to
3b9fea9
Compare
56564ee
to
59bd248
Compare
59bd248
to
965863b
Compare
@snguyen64 i just remember one thing, we might need those. o files for vendoring as well since they are embedded in the generated ebpf wrapper files. |
This PR will be closed in 7 days due to inactivity. |
Pull request closed due to inactivity. |
Description
Updates to the dev container to use kind and kind registry for local testing.
Removes generated files including mocks
Update mock generates to be consistent
Update linting to 1.60.3 for workflow and local lint and update deprecated linters.
Related Issue
If this pull request is related to any issue, please mention it here. Additionally, make sure that the issue is assigned to you before submitting this pull request.
Checklist
git commit -S -s ...
). See this documentation on signing commits.Screenshots (if applicable) or Testing Completed
Please add any relevant screenshots or GIFs to showcase the changes made.
Additional Notes
Add any additional notes or context about the pull request here.
Please refer to the CONTRIBUTING.md file for more information on how to contribute to this project.