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

fix(feature): preserves original target namespace #1148

Conversation

bartoszmajsak
Copy link
Contributor

@bartoszmajsak bartoszmajsak commented Jul 31, 2024

Description

This change ensures that original target namespace is used when invoked directly in the builder.

Typically subsequent calls of .TargetNamespace in the feature builder indicate coding/copy-paste error and should be reduced to one.

However,in the FeatureHandler, where we group features together we do not have to specify target namespace for each feature, as it is defaulted to the one defined on the handler level. This is convenient, but limits application of features to a single namespace, as the value is always overwritten.

How Has This Been Tested?

By running make tests.

Screenshot or short clip

Merge criteria

  • You have read the contributors guide.
  • Commit messages are meaningful - have a clear and concise summary and detailed explanation of what was changed and why.
  • Pull Request contains a description of the solution, a link to the JIRA issue, and to any dependent or related Pull Request.
  • Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
  • The developer has manually tested the changes and verified that the changes work

This change ensures that original target namespace is used when invoked
directly in the builder.

Typically subsequent calls of .TargetNamespace in the feature builder
indicate coding/copy-paste error and should be reduced to one.

However,in the FeatureHandler, where we group features together we do not have
to specify target namespace for each feature, as it is defaulted to the
one defined on the handler level. This is convenient, but limits
application of features to a single namespace, as the value is always
overwritten.
@bartoszmajsak bartoszmajsak removed the request for review from adelton July 31, 2024 19:13
@bartoszmajsak
Copy link
Contributor Author

/retest

@zdtsw zdtsw removed the request for review from ajaypratap003 August 1, 2024 06:25
@@ -67,9 +67,11 @@ func (fb *featureBuilder) Source(source featurev1.Source) *featureBuilder {
}

// TargetNamespace sets the namespace in which the feature should be applied.
// If not set, the feature will be applied in the application namespace.
// Calling it multiple times in the builder chain will have no effect, as the first value is used.
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 the original comments is still valid, but with this new one to explain the case "if it has been set"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not on this level, no. If not set it will fail. Implicitly setting the target namespace before building feature is done in the handler, but that's different.

@openshift-ci openshift-ci bot added the lgtm label Aug 1, 2024
Copy link

openshift-ci bot commented Aug 1, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: zdtsw

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved label Aug 1, 2024
@openshift-merge-bot openshift-merge-bot bot merged commit a890ffa into opendatahub-io:incubation Aug 1, 2024
8 checks passed
zdtsw pushed a commit to zdtsw-forking/rhods-operator that referenced this pull request Aug 2, 2024
This change ensures that original target namespace is used when invoked
directly in the builder.

Typically subsequent calls of .TargetNamespace in the feature builder
indicate coding/copy-paste error and should be reduced to one.

However,in the FeatureHandler, where we group features together we do not have
to specify target namespace for each feature, as it is defaulted to the
one defined on the handler level. This is convenient, but limits
application of features to a single namespace, as the value is always
overwritten.
zdtsw pushed a commit to zdtsw-forking/rhods-operator that referenced this pull request Aug 2, 2024
This change ensures that original target namespace is used when invoked
directly in the builder.

Typically subsequent calls of .TargetNamespace in the feature builder
indicate coding/copy-paste error and should be reduced to one.

However,in the FeatureHandler, where we group features together we do not have
to specify target namespace for each feature, as it is defaulted to the
one defined on the handler level. This is convenient, but limits
application of features to a single namespace, as the value is always
overwritten.

(cherry picked from commit a890ffa)
openshift-merge-bot bot pushed a commit to red-hat-data-services/rhods-operator that referenced this pull request Aug 2, 2024
This change ensures that original target namespace is used when invoked
directly in the builder.

Typically subsequent calls of .TargetNamespace in the feature builder
indicate coding/copy-paste error and should be reduced to one.

However,in the FeatureHandler, where we group features together we do not have
to specify target namespace for each feature, as it is defaulted to the
one defined on the handler level. This is convenient, but limits
application of features to a single namespace, as the value is always
overwritten.

(cherry picked from commit a890ffa)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants