Update HTTP Response For Not Allowed Requests

[Jdubrick]

Please specify the area for this PR

What does does this PR do / why we need it:
This PR updates our API endpoints to properly return a 405 response code for methods that are not allowed (in this case POST/PUT/DELETE), currently all of our endpoints only support GET requests and any other request was returning a 404 code.

Which issue(s) this PR fixes:

Fixes devfile/api#543

PR acceptance criteria:

• Test Coverage
  • Are your changes sufficiently tested, and are any applicable test cases added or updated to cover your changes?

Documentation (WIP)

• Does the REST API doc need to be updated with your changes?
• Does the registry library doc need to be updated with your changes?

How to test changes / Special notes to the reviewer:
Unit tests have been added to make sure they are returning the proper response codes. If you wish you can also spin up the registry on a cluster and test the endpoints using something like Postman.

[codecov]

Codecov Report

Attention: 641 lines in your changes are missing coverage. Please review.

Comparison is base (19c1c08) 35.58% compared to head (2cc139c) 27.23%.

❗ Current head 2cc139c differs from pull request most recent head b5a9e5c. Consider uploading reports for the commit b5a9e5c to get more accurate results

Files	Patch %	Lines
index/server/pkg/server/endpoint.gen.go	0.00%	641 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #199      +/-   ##
==========================================
- Coverage   35.58%   27.23%   -8.36%     
==========================================
  Files           7        7              
  Lines        1360     2012     +652     
==========================================
+ Hits          484      548      +64     
- Misses        829     1417     +588     
  Partials       47       47              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Jdubrick]

/retest

[Jdubrick]

Going to investigate if there is a way to exempt generated source code from the code coverage check. It appears that before my change as well all the generated .gen.go files were being marked as missed.

[thepetk]

/lgtm tried it locally with postman and I'm able to see the differences between the fixed version and the registry.devfile.io/index

[Jdubrick]

I believe we can ignore the generated source code by referencing here: https://docs.codecov.com/docs/ignoring-paths#ignoring-specific-file-types

By adding **/*.gen.go to https://github.com/devfile/registry-support/blob/main/.codecov.yaml#L37

WDYT @thepetk @michael-valdron

[michael-valdron]

/lgtm

Failing code coverage could be based off prior recorded source changes or using current state of .codecov.yaml under the main branch rather than the PR changed file.

We should watch out for these failures in upcoming PRs.

[Jdubrick]

/lgtm

Failing code coverage could be based off prior recorded source changes or using current state of .codecov.yaml under the main branch rather than the PR changed file.

We should watch out for these failures in upcoming PRs.

Testing out trying to explicitly state the path of a generated code file to ignore because when I looked at the pull it still stated that index/server/pkg/server/endpoint.gen.go was still uncovered but that didn't seem to do the trick either. I think to your comment it has the changes cached and won't recursive change the coverage report if we ignore something for this PR. I'm probably going to revert back to the **/*.gen.go ignore, should I just push it through without codecov pass?

@michael-valdron

[michael-valdron]

/lgtm
Failing code coverage could be based off prior recorded source changes or using current state of .codecov.yaml under the main branch rather than the PR changed file.
We should watch out for these failures in upcoming PRs.

Testing out trying to explicitly state the path of a generated code file to ignore because when I looked at the pull it still stated that index/server/pkg/server/endpoint.gen.go was still uncovered but that didn't seem to do the trick either. I think to your comment it has the changes cached and won't recursive change the coverage report if we ignore something for this PR. I'm probably going to revert back to the **/*.gen.go ignore, should I just push it through without codecov pass?

@michael-valdron

@Jdubrick If I'm understanding correctly, you would like to revert the change to code coverage ignores, **/*.gen.go, and handle this issue separately. I'm good with doing this to scope this PR to the tied issue and track the addition of ignoring generated source code in a separate issue.

[Jdubrick]

/lgtm
Failing code coverage could be based off prior recorded source changes or using current state of .codecov.yaml under the main branch rather than the PR changed file.
We should watch out for these failures in upcoming PRs.

Testing out trying to explicitly state the path of a generated code file to ignore because when I looked at the pull it still stated that index/server/pkg/server/endpoint.gen.go was still uncovered but that didn't seem to do the trick either. I think to your comment it has the changes cached and won't recursive change the coverage report if we ignore something for this PR. I'm probably going to revert back to the **/*.gen.go ignore, should I just push it through without codecov pass?

@Jdubrick If I'm understanding correctly, you would like to revert the change to code coverage ignores, **/*.gen.go, and handle this issue separately. I'm good with doing this to scope this PR to the tied issue and track the addition of ignoring generated source code in a separate issue.

@michael-valdron I was trying to say that I would revert my commit back to the one that excludes **/*.gen.go to take care of all generated go files in this repo. I had a commit after that where I tried to do a more explicit path because I thought that would work. That I have now removed.

We could open an issue into investigating how to backdate the exclusions, and if there is a potential fix to resolve it. My changes to .codecov.yaml to exclude the generated files aren't going to fix anything at this point because of the issue we identified where it is not backdating the change, so all the coverage reports prior to this PR have those missing coverage lines and it is comparing against that still.

The issue now would be that merging this PR will have the 2 failures for code coverage but you said above that is fine. I agree with that especially if we open an issue into investigating a fix for the coverage. I can open that issue soon.

[michael-valdron]

/lgtm
Failing code coverage could be based off prior recorded source changes or using current state of .codecov.yaml under the main branch rather than the PR changed file.
We should watch out for these failures in upcoming PRs.

Testing out trying to explicitly state the path of a generated code file to ignore because when I looked at the pull it still stated that index/server/pkg/server/endpoint.gen.go was still uncovered but that didn't seem to do the trick either. I think to your comment it has the changes cached and won't recursive change the coverage report if we ignore something for this PR. I'm probably going to revert back to the **/*.gen.go ignore, should I just push it through without codecov pass?

@Jdubrick If I'm understanding correctly, you would like to revert the change to code coverage ignores, **/*.gen.go, and handle this issue separately. I'm good with doing this to scope this PR to the tied issue and track the addition of ignoring generated source code in a separate issue.

@michael-valdron I was trying to say that I would revert my commit back to the one that excludes **/*.gen.go to take care of all generated go files in this repo. I had a commit after that where I tried to do a more explicit path because I thought that would work. That I have now removed.

We could open an issue into investigating how to backdate the exclusions, and if there is a potential fix to resolve it. My changes to .codecov.yaml to exclude the generated files aren't going to fix anything at this point because of the issue we identified where it is not backdating the change, so all the coverage reports prior to this PR have those missing coverage lines and it is comparing against that still.

The issue now would be that merging this PR will have the 2 failures for code coverage but you said above that is fine. I agree with that especially if we open an issue into investigating a fix for the coverage. I can open that issue soon.

@Jdubrick Sorry for misunderstanding just realized what you meant 😆

Yeah I agree with reverting to the pattern since that is more what we are trying to cover with the ignore anyway.

Also, +1 on an investigation issue, would be good to open as a follow up to this not respecting the ignore. I would see what the result is on the main branch after this PR is merged first.

[michael-valdron]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Jdubrick, michael-valdron, thepetk

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:

• OWNERS [Jdubrick,michael-valdron,thepetk]

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