After doing some initial work on this integration, I've stumbled across the first drawbacks regarding semantic differences between Github and Gitlab.

To begin with, even though Gitlab manages the concept of releases, they don't have a proper identifier but only add to the tag some release notes and optionally some attachments. In addition, and maybe surprisingly, such attachments, which could be assimilated to Github assets, are not accessible via API, but only through the web UI. There's an open issue tracking this problem.

To make the long story short, these shortcomings of the Gitlab API would affect directly to these two verbs of the algebra:

GetRelease(slug: Slug, releaseId: ID, t: AccessToken)
GetReleaseAssetContent(asset: Github.Asset, t: AccessToken)

To expand information on what the Gitlab API supports, mention that git tags are supported but can only be identified by their name or tag_name.

Thinking about solutions, we could associate the release with the tag but in that case we need to keep in mind that we would not have an ID of type Long but a tagName of type String. As for assets, I think we might ignore them, for the Gitlab case at least, and allow to add the * -deployable.yml file to the repository next to the source code.

WDYT?

/cc @timperrett @rossabaker

@juanjovazquez if you need any help, I'd very happily help you. I'm interested in nelson and GitLab support is mandatory here.

@daddykotex Unfortunately my work on Nelson is stalled for the time being as it's not currently a priority for our team. Please, feel free to revamp this effort if it's important for you. This PR tried to overcome the fact that Nelson, at least at that time, wasn't flexible enough to extend to other SCM's and adopted a pragmatic approach. Maybe the situation has changed and now it's easier to implement the elegant and consistent solution that maintainers had in mind.

Allright, thank you for your work. I will have a look when I come back from holidays.

Any update in this ?

We're working on building a new CD process at the inception phase of a new product launch, and what we choose now will play as a major ongoing part of our CI/CD Strategy and product evolution.

GitLab support is essential to that path, or we'll have to look elsewhere for perhaps a less functional solution; but regrettably one that aligns with out current SCM tooling, and an SCM switch has a lot of complex implications.

Whilst we do have "some" more time for consideration, is support for other (git based) SCM solutions on the Nelson roadmap or is the GitHub integration intrinsic in the design and implementation?

Without a dedicated maintainer for this feature I don’t think it will land. The biggest problem we have is that nobody actively involved in Nelson development is able to verify such a big change - so we would probally end up breaking things during refactoring.

I am totally open to having a better path for testing that enable us to know if we broke things; if we had that we would at least have some confidence 😎 from a technical standpoint, there is no fundamental limitation that restricts us to GitHub, but we can’t adopt those implementations without a way to test and verify changes.

@timperrett thanks for the update.

@goedelsoup via Gitter also noted that "not currently. more recently GitHub Deployments were set up to be the engine of Nelson so that definitely makes introducing the support at a later date a bit more difficult as well."

We'll take this information under advisement - either way were very impressed with what you are putting together with Nelson.