GitLab/GitHub

[nathansmonk]

GitLab/GitHub

[cookpete]

My immediate thought is to simply render the correct links based on the origin URL (without the need for a separate template) which shouldn't be too hard to do. I'm also currently planning a refactor to support custom template config files, which will give much more flexibility.

[cookpete]

https://gitlab.hexonet.net:44447/front-end-team/ispapi-securityheaders/compare/v2.1.0...v2.1.1 (that's the link in changelog produced by the template -> doesn't work)

@Papakai This should be sorted in 0.3.6

run on a gitlab repo, but all the links read github.com...

@nathansmonk This should not be happening. parse-github-url is used to parse the origin remote of whatever git repo you are in. Even though github is in the package name, it is not specific to github repo URLs. GitLab repos should produce GitLab links, which @Papakai seems to confirm is happening as expected. If this is still a problem, do you have more details or an example case where it is happening?

[KaiSchwarz-cnic]

+1

we are also using gitlab internally. The history file looks good, up to the links to compare the versions.
e.g.
https://<gitlabhost>/<team>/<project>/compare/v2.0.0...v2.0.1 which is not supported by gitlab itself

I haven't found a better way for now, but in case we work with merged branches, so one commit per module version, you could cover it like follows:
e.g.
https://<gitlabhost>/<team>/<project>/commit/<commitid> which displays the diff.

Would be great if you could simply create a copy of your two templates with reviewed links and to provide them as Gitlab.Compact.js and Gitlab.Default.js

[cookpete]

e.g.
https://<gitlabhost>/<team>/<project>/compare/v2.0.0...v2.0.1 which is not supported by gitlab itself

@Papakai are you sure? The following seems to work:

https://gitlab.com/gitlab-org/gitlab-ce/compare/v9.5.9...v10.0.4

[KaiSchwarz-cnic]

You're right it works. Sorry, I have not recognized that your template generates a wrong url including ssh port after hostname which won't work for http.

https://gitlab.hexonet.net/front-end-team/ispapi-securityheaders/compare/v2.1.0...v2.1.1 (works!)
https://gitlab.hexonet.net:44447/front-end-team/ispapi-securityheaders/compare/v2.1.0...v2.1.1 (that's the link in changelog produced by the template -> doesn't work)

just note the the above urls are not reachable in public, take them just as example / reference.

[KaiSchwarz-cnic]

will give that a try in the next days. thanks!

[nathansmonk]

Tried again, but still had the same thing happen.

Running git remote get-url origin returned [email protected]:wearesmile/glass.git so the origin is correct.

I ran npm install auto-changelog and then auto-changelog

However, the resulting CHANGELOG.md was...

All notable changes to this project will be documented in this file. This project adheres to [Semantic Versioning](http://semver.org/).

Generated by [auto-changelog](https://github.com/CookPete/auto-changelog)


## Unreleased

### Fixed
* Fixes #2 [`#2`](https://github.com/wearesmile/glass/issues/2)
* Fixes #12 [`#12`](https://github.com/wearesmile/glass/issues/12)

[cookpete]

@nathansmonk Good spot. It was due to this issue with parse-github-url which is now fixed in the latest version. I'll bump the version that auto-changelog uses and it should be sorted.

This has given me another thought.. perhaps we need the ability to pass in a custom web repo URL for when the origin remote and the repo URLs differ. In @Papakai's example it happens to be ok because the repo URL:

https://gitlab.hexonet.net/front-end-team/ispapi-securityheaders

is the same as the origin URL without the port:

https://gitlab.hexonet.net:44447/front-end-team/ispapi-securityheaders

But what if the web repo was hosted on a private server with a different port?

https://gitlab.hexonet.net:8080/front-end-team/ispapi-securityheaders

There would be no way for auto-changelog to know where to link to.

[KaiSchwarz-cnic]

@cookpete I gave it a try, the port is now removed correctly. But as protocol, ssh:// appears in the version and commit id links instead of https.

[cookpete]

I give it a try, the port is now removed correctly. But as protocol, ssh:// appears in the version and commit id links instead of https.

Good spot. Should be fixed in 1.0.3

[KaiSchwarz-cnic]

@cookpete Thanks for the fix. as improvement idea: you could simply use '//' as protocol which automatically uses the one currently in use as far as I remember.

e.g.

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js"></script>

Read: https://www.paulirish.com/2010/the-protocol-relative-url/