Support on prem GitHub release notes / changelog

[eugeniyk]

Currently we have github.com and other urls hardcoded in the code, which makes it unusable in environments with different on-prem domain names.

Fixes #1088

[codecov]

Codecov Report

Merging #1563 into master will increase coverage by 0.13%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1563      +/-   ##
==========================================
+ Coverage   70.63%   70.77%   +0.13%     
==========================================
  Files         113      113              
  Lines        1822     1827       +5     
  Branches       53       51       -2     
==========================================
+ Hits         1287     1293       +6     
+ Misses        535      534       -1     

Impacted Files	Coverage Δ
.../scala/org/scalasteward/core/vcs/VCSExtraAlg.scala	100.00% <ø> (ø)
...main/scala/org/scalasteward/core/vcs/package.scala	100.00% <100.00%> (ø)
...g/scalasteward/core/application/SupportedVCS.scala	53.84% <0.00%> (+7.69%)	⬆️

---

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 6525ca6...68393ed. Read the comment docs.

[mzuehlke]

Your change would restrict linking to release notes to only the VCS the current installation is running on.
In the current implementation the scala steward instance running on Gitlab or even on-prem could link to release notes on e.g. github.com. After your change this would not be possible anymore.

Should this PR address: #1088 ? Just to understand your motivation.

[eugeniyk]

@mzuehlke I've got your point, I thought it's trying to compare within current github installation.
currently our github installation uses "github.domain.io", making it's impossible to link CHANGELOG for local dependencies

Seems #1088 describes exactly my problem

[eugeniyk]

@mzuehlke looks like we can solve it this way:

1. if repoUri starts with Config.vcsApiHost then we can use Config.vcsType and apply current PR changes
2. otherwise fallback to the current implementation

WDYT?

[mzuehlke]

I think your proposal looks like a perfect way to solve this issue. 👍

[eugeniyk]

Looks like false alarm for me

[eugeniyk]

@mzuehlke please review again

[eugeniyk]

@fthomas could you please review this PR? The Codacy failure sounds like false positive

[mzuehlke]

A really good PR.
Let me know what you think about my comments.
But I'm fine with merging this PR like it is now.

[mzuehlke]

one more, related to the first comment:
extractRepoVCSType could live in VCSExtraAlg and you would only need to pass the RepoVCSType.

[eugeniyk]

then possibleCompareUrls and possibleReleaseRelatedUrls would need to be extracted to VCSExtraAlg as well (right now it's in package object), which make sense for me as well

I can try to make it as separated PR

[eugeniyk]

@mzuehlke have it as separated PR here: eugeniyk#1
I think we can merge #1563 as is and continue with refactorings in PR above, wdyt?

[mzuehlke]

Thanks @eugeniyk for contributing to scala-steward 👍

[eugeniyk]

@mzuehlke glad to improve this awesome tool!