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

tool(dev): update dev container, makefile, remove object files #609

Closed
wants to merge 10 commits into from

Conversation

snguyen64
Copy link
Contributor

@snguyen64 snguyen64 commented Aug 15, 2024

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

  • I have read the contributing documentation.
  • I signed and signed-off the commits (git commit -S -s ...). See this documentation on signing commits.
  • I have correctly attributed the author(s) of the code.
  • I have tested the changes locally.
  • I have followed the project's style guidelines.
  • I have updated the documentation, if necessary.
  • I have added tests, if applicable.

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.

@snguyen64 snguyen64 force-pushed the feat/dev-update branch 2 times, most recently from 90bf985 to 041eebb Compare August 15, 2024 21:12
@snguyen64 snguyen64 changed the title tools(dev): update dev container, makefile, remove object files tool(dev): update dev container, makefile, remove object files Aug 15, 2024
@snguyen64 snguyen64 marked this pull request as ready for review August 15, 2024 21:15
@snguyen64 snguyen64 requested a review from a team as a code owner August 15, 2024 21:15
@nddq
Copy link
Contributor

nddq commented Aug 15, 2024

hmm pretty sure we needed those empty object files, so the linter doesn't complain 🤔

@snguyen64 snguyen64 force-pushed the feat/dev-update branch 12 times, most recently from 0f5a249 to 1418ed7 Compare August 16, 2024 20:56
Comment on lines 8 to +9
curl -sL https://apt.llvm.org/llvm.sh | sudo bash -s "$LLVM_VERSION"
echo 'export PATH=$PATH:/usr/lib/llvm-14/bin' >> ~/.profile
Copy link
Collaborator

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?

Copy link
Collaborator

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?

Copy link
Contributor Author

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

Copy link
Member

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.

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 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

@@ -13,7 +13,6 @@ $ go install ...
package tools

import (
_ "github.com/golangci/golangci-lint/cmd/golangci-lint"
Copy link
Collaborator

Choose a reason for hiding this comment

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

why?

Copy link
Collaborator

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

Copy link
Contributor Author

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
Copy link
Collaborator

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?

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 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

Copy link
Collaborator

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

Copy link
Member

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).

Makefile Outdated Show resolved Hide resolved
.github/workflows/golangci-lint.yaml Outdated Show resolved Hide resolved
@snguyen64 snguyen64 force-pushed the feat/dev-update branch 9 times, most recently from 3df6854 to 41a9d4c Compare August 20, 2024 22:49
@snguyen64 snguyen64 marked this pull request as draft August 27, 2024 23:18
@snguyen64 snguyen64 force-pushed the feat/dev-update branch 6 times, most recently from d22a563 to 50148ec Compare August 28, 2024 17:55
@snguyen64 snguyen64 force-pushed the feat/dev-update branch 4 times, most recently from 56564ee to 59bd248 Compare August 28, 2024 20:32
@snguyen64 snguyen64 marked this pull request as ready for review August 28, 2024 21:43
@nddq
Copy link
Contributor

nddq commented Sep 4, 2024

@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. go mod vendor will not success IIRC, but you can verify it

Copy link

github-actions bot commented Oct 5, 2024

This PR will be closed in 7 days due to inactivity.

@github-actions github-actions bot added the meta/waiting-for-author Blocked and waiting on the author label Oct 5, 2024
Copy link

Pull request closed due to inactivity.

@github-actions github-actions bot closed this Oct 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta/waiting-for-author Blocked and waiting on the author
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants