Remove redundant code and fix flag option

[bmeneg]

This MR has three different and minor fixes:

1. Remove redundant code in internal/gitlab/gitlab.go::FindProject()
2. The --project value was being used as the value for token variable instead of --token value.

Check the individual commits for more information.

[codecov]

Codecov Report

Merging #734 (1326331) into master (2fb6734) will increase coverage by 0.09%.
The diff coverage is 45.23%.

@@            Coverage Diff             @@
##           master     #734      +/-   ##
==========================================
+ Coverage   54.71%   54.81%   +0.09%     
==========================================
  Files          77       77              
  Lines        5596     5610      +14     
==========================================
+ Hits         3062     3075      +13     
- Misses       2251     2253       +2     
+ Partials      283      282       -1     

Impacted Files	Coverage Δ
cmd/ci_run.go	64.70% <0.00%> (ø)
cmd/mr_approve.go	70.27% <33.33%> (-1.61%)	⬇️
cmd/mr_unapprove.go	75.00% <47.36%> (+3.12%)	⬆️
cmd/note_common.go	54.57% <66.66%> (-0.24%)	⬇️
internal/gitlab/gitlab.go	7.27% <100.00%> (+0.20%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fd3d2ce...1326331. Read the comment docs.

[zaquestion]

I think we don't actually need to deprecate the --project flag see comments and getCIRunOptions

[zaquestion]

Ah I'm realizing that marking for deprecation doesn't disable the functionality, tho I still have some concerns about removing it down the line. Despite the inconsistency in the tool, very fair assessment there, the --project flag serves a real purpose and powers a real workflow, which is consistent with the goals of the project ( as in it's not there just for api completeness, it's there because it's useful for doing a particular thing). At the least I'd suggest we open an issue to discuss how to support this in a way more consistent with the repo. I would also check what the lab ci status command does as I believe I added a way to specify project for that as part of #240

[zaquestion]

downgrading my request for changes to a request for comment

[bmeneg]

@zaquestion I replied to your specific comments in the code before realizing you did a general comment in the PR.
My comments to your comments still applies though :)

[bmeneg]

ahh.. obviously I missed the lab ci status. Will check that as well and, possibly, open an issue to discuss it or to inform a possible conclusion (if we get to one here 😄)

[prarit]

@bmeneguele , this PR is still in draft after 20 days. Is that intentional? I've been holding off reviewing until it was "Ready". Maybe that was a mistake on my part?

[bmeneg]

@prarit no, it's intentional. I need to come back to this code and rework. But unfortunately I had no time to rethink it yet.

[bmeneg]

To move this PR forward I'm going to remove the "deprecation" commit and move it to the next PR I'm preparing with the --follow logic.

[bmeneg]

@zampierilucas @prarit @zaquestion please, feel free to re-review this patch, like I said in the previous comment, the part that generated the whole discussion was removed. I'll do that in the next PR. With that, only two really simple commits were left.

[bmeneg]

downgrading my request for changes to a request for comment

Considering the above comment from @zaquestion and also the fact I'm going to open a new PR with the changes we discussed here so far, I'm going ahead and merge this PR.

A new PR will be created with a more contextualized change set.