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

Refactor and simplify structs (#2314) #20

Merged
merged 1 commit into from
Oct 13, 2022

Conversation

keithchong
Copy link
Collaborator

The initial HAS struct types were maintained. The goal now is to simplify, especially when the ComponentSpec configuration and the BindingComponentConfiguration have overlap. (They are both used primarily in the generation of the basic k8s deployment.yaml).

Each element in the BindingComponentConfiguration is mapped nicely to the ComponentSpec, except for Resources, where in the former, the ResourceRequirement is a pointer, but, in the latter, it is a non-pointer. This PR will use a non-pointer. Similarly, this reflects how it is done in k8s Container. See
https://github.com/kubernetes/api/blob/6dd661f592205cc6035520138ebdbd271b9fa197/core/v1/types.go#L2369

The goal is ‘flatten’ the structs and simplify, so the elements from ComponentSpec will be moved to the Component struct. The Source element will have the ComponentSource type however, and these types are flattened too. (There isn’t a need for multiple GitSources and Unions so this PR simplifies this.)

Mapping:
Original: component.Spec.Source.ComponentSourceUnion.GitSource, where GitSource is a pointer to GitSource
New: component.Source.ComponentSource, where Source is a pointer to ComponentSource

This is so that you can check for a nil ComponentSource. See the corresponding changes in the Application Service PR. This is similar to checking if component.Spec.Source.ComponentSourceUnion.GitSource != nil

Signed-off-by: Keith Chong kykchong@redhat.com

@keithchong
Copy link
Collaborator Author

Changes to HAS are in this branch, excluding the go.mod file (just pull in the changes from this PR to see)

https://github.com/keithchong/application-service/tree/2314-ReactToRefactoredStructsFromGitOpsGenerator

@keithchong
Copy link
Collaborator Author

Here is the commit (differences) in HAS:

redhat-appstudio/application-service@e96d0e2

pkg/gitops.go Outdated Show resolved Hide resolved
@@ -38,18 +39,11 @@ type GitSource struct {
DockerfileURL string `json:"dockerfileUrl,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there an order of precedence for component creation if the URL, DevfileURL, and DockerfileURLs are all specified at once? Should this be documented?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Right now, they are placeholders. Those are currently not used by the Generator - only the URL is used.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Based on your later review comments, I'll get rid of these.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't know if this will break HAS. If these are HAS specific, then they belong in the HAS repo. They don't really fit the category of "git source" either. cc @maysunfaisal

api/v1alpha1/component_types.go Outdated Show resolved Hide resolved
@@ -62,103 +56,27 @@ type ComponentSpec struct {
Secret string `json:"secret,omitempty"`

// Source describes the Component source
Source ComponentSource `json:"source,omitempty"`
Source *ComponentSource `json:"source,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

how about

Suggested change
Source *ComponentSource `json:"source,omitempty"`
GitSource *GitSource `json:"gitSource,omitempty"`

because ContainerImage can also be a source. This would mean also renaming type ComponentSource struct{}

I am thinking about making this change in the application-service too after thinking about it now. it looks cleaner

api/v1alpha1/component_types.go Outdated Show resolved Hide resolved
@keithchong
Copy link
Collaborator Author

Note that the definition of Resource is different in GitOps service and HAS:

Managed GitOps Services

https://github.com/redhat-appstudio/managed-gitops/blob/864c0c9c5a743275a4b0e497654a9220a4fb993f/appstudio-shared/apis/appstudio.redhat.com/v1alpha1/applicationsnapshotenvironmentbinding_types.go#L67

HAS

https://github.com/redhat-appstudio/application-service/blob/0b7dd2d0dc4d9a31c6803a9bbbab2b985ddbbcdf/api/v1alpha1/component_types.go#L89

Both are used when generating the deployment file (deployment kind). I've changed it to be a non-pointer. See the component_types.go file.

@keithchong
Copy link
Collaborator Author

Here is the updated commit in HAS to reflect these changes

redhat-appstudio/application-service@93fd73a

@keithchong
Copy link
Collaborator Author

keithchong commented Sep 29, 2022

Here is the latest commit for the HAS repo to reflect these changes. A follow-on PR for that will be created including updating the go.mod file, etc. (It just has the source changes)

redhat-appstudio/application-service@a951ab0

Copy link
Collaborator

@maysunfaisal maysunfaisal left a comment

Choose a reason for hiding this comment

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

  • Just a suggestion to change function param to options since we changed the struct name
  • pls have a look at my ENV suggestion for deployment patch func, is it valid?

type GitSource struct {
// If importing from git, the repository to create the component from
URL string `json:"url"`

// Specify a branch/tag/commit id. If not specified, default is `main`/`master`.
Revision string `json:"revision,omitempty"`
//Revision string `json:"revision,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we might need to keep this

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

These are not used anywhere in the source so far.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Collaborator Author

@keithchong keithchong Oct 12, 2022

Choose a reason for hiding this comment

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

That is application-service's original types. Note that a duplicate of these types (structs) were made in the common library to make the transition to the library easier. This duplicate or the 'mapping' now needs to be reduced because many of the fields are not necessary when generating the k8s resources. If you need any field added to the 'mapping', then that field must be used by the library in some way. Currently, what you see now in this PR are the fields that are used.

pkg/generate.go Outdated Show resolved Hide resolved
pkg/generate.go Outdated Show resolved Hide resolved
pkg/generate.go Outdated Show resolved Hide resolved
pkg/generate.go Outdated Show resolved Hide resolved
pkg/generate.go Outdated Show resolved Hide resolved
pkg/gitops.go Outdated Show resolved Hide resolved
pkg/gitops.go Outdated Show resolved Hide resolved
pkg/gitops.go Outdated Show resolved Hide resolved
pkg/gitops.go Outdated Show resolved Hide resolved
@keithchong keithchong force-pushed the 2314-RefactorStructs branch 2 times, most recently from 79f1b38 to 48d8f3f Compare October 12, 2022 21:18
@keithchong
Copy link
Collaborator Author

  • Just a suggestion to change function param to options since we changed the struct name
  • pls have a look at my ENV suggestion for deployment patch func, is it valid?

I also renamed the file in api/v1alpha1 from component_types.go to generator_options.go

@codecov-commenter
Copy link

codecov-commenter commented Oct 12, 2022

Codecov Report

Base: 81.63% // Head: 80.67% // Decreases project coverage by -0.96% ⚠️

Coverage data is based on head (42a9ef1) compared to base (ad5e970).
Patch coverage: 88.40% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #20      +/-   ##
==========================================
- Coverage   81.63%   80.67%   -0.97%     
==========================================
  Files           6        6              
  Lines         588      595       +7     
==========================================
  Hits          480      480              
- Misses         99      106       +7     
  Partials        9        9              
Impacted Files Coverage Δ
pkg/gitops.go 57.78% <55.55%> (-2.53%) ⬇️
pkg/generate.go 90.54% <100.00%> (+0.06%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@keithchong
Copy link
Collaborator Author

Here are the latest rebased changes to the application-service to react to these changes (minus the go.mod changes)

redhat-appstudio/application-service@94e3c99

Signed-off-by: Keith Chong <kykchong@redhat.com>
@keithchong
Copy link
Collaborator Author

Thanks for the review folks. We needed to rebase again.

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.

4 participants