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

Integrate Sustainable Views draft annotations #70

Merged
merged 3 commits into from
Mar 20, 2024

Conversation

asparuhft
Copy link

@asparuhft asparuhft commented Mar 18, 2024

Description

What

Integrate Sustainable Views draft annotations

Why

JIRA Ticket UPPSF-4920

Anything, in particular, you'd like to highlight to reviewers

Mention here sections of code which you would like reviewers to pay extra attention to .E.g

Would appreciate a second pair of eyes on the test
I am not quite sure how this bit works
Is there a better library for doing x

Scope and particulars of this PR (Please tick all that apply)

  • Tech hygiene (dependency updating & other tech debt)
  • Bug fix
  • Feature
  • Documentation
  • Breaking change
  • Minor change (e.g. fixing a typo, adding config)

DoD - Ensure all relevant tasks are completed before marking this PR as "Ready for review"

  • Test coverage is not significantly decreased
  • All PR checks have passed
  • Changes are deployed on dev before asking for review
  • Documentations remains up-to-date
    • OpenAPI definition file is updated
    • README file is updated
    • Documentation is updated in upp-docs and upp-public-docs
    • Architecture diagrams are updated

This Pull Request follows the rules described in our Pull Requests Guide

@asparuhft asparuhft requested a review from a team as a code owner March 18, 2024 15:13
@angelraynovft angelraynovft requested a review from a team March 20, 2024 08:03
Copy link
Contributor

@ManoelMilchev ManoelMilchev left a comment

Choose a reason for hiding this comment

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

question: I see that we are moving to []interface{} instead of specific structure, is that because we want to be ready for future custom fields in annotations ?

@@ -228,6 +235,7 @@ func TestWriteMissingTID(t *testing.T) {
}
}

// nolint:all
Copy link
Contributor

Choose a reason for hiding this comment

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

question: Why the nolint: all here?

Copy link
Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

You can place _ for unused parameters and the linter will be happy.

Copy link
Author

Choose a reason for hiding this comment

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

Correct, I will update the tests in the next PR.

annotations/augmenter.go Outdated Show resolved Hide resolved
if err != nil {
handleWriteErrors("Error decoding request body", err, writeLog, w, http.StatusBadRequest)
return
}

if !mapper.IsValidPACPredicate(addedAnnotation.Predicate) {
addedAnnotation := addedAnnotationBody["annotation"].(map[string]interface{})
Copy link
Contributor

Choose a reason for hiding this comment

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

question: Throughout the code there are many places where we are using type assertion without checking if it was successful, we are doing this because we are aware of what is contained in the interface, however this makes the program less panic proof. Do you think we should handle type assertion checks throughout the code?

Copy link
Author

Choose a reason for hiding this comment

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

Yes you are correct. In theory we should handle type assertion checks throughout the code. However with the next PR we would place validation on the incoming requests, which should minimise the risk of panics. Therefore I have decided not to do so many type assertion checks to make the code more readable/clean.

@asparuhft
Copy link
Author

question: I see that we are moving to []interface{} instead of specific structure, is that because we want to be ready for future custom fields in annotations ?

Yes we are preparing the service for future custom fields in the new types of annotations.

Copy link
Contributor

@ManoelMilchev ManoelMilchev left a comment

Choose a reason for hiding this comment

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

LGTM!

annotations/augmenter.go Outdated Show resolved Hide resolved
Co-authored-by: Manoel Milchev <84855838+ManoelMilchev@users.noreply.github.com>
@asparuhft asparuhft merged commit b302f2d into publishing-cluster Mar 20, 2024
3 checks passed
@asparuhft asparuhft deleted the feature/UPPSF-4920 branch March 20, 2024 09:42
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.

None yet

3 participants