Release notes as comment on commit (not MR)

[akashgupta88]

We are using semantic-release on our Gitlab hosted environment to deploy packages to great effect.

In our case however there is one difference, the code is generated and pushed to the repository as commits on master, and we would like to see what version of the package was deployed on every commit from which the release is made.

Sometimes when changes need to be manually added they are done as MR, and we do see the release notes getting commented on the merged MRs.

Is there a way to get the same note pushed as comment on the commit as well?

[fgreinacher]

Not at the moment, is this possible via the GitLab API?

[JonasSchubert]

If I understood the use case correct it could be done with this. Is this what you meant, @akashgupta88 ?

[akashgupta88]

@fgreinacher yes it is possible using the API that @JonasSchubert correctly pointed out.

[fgreinacher]

Cool! Next step would be to think about how to configure this. Should be opt-in and not conflict with existing commenting features.

[travi]

does the tag added by semantic-release not accomplish this goal?

[akashgupta88]

@travi it actually does but partly.

• For the purpose of looking up which version was deployed against a commit, tags do the job.
• However with comments, we are looking to be notified as watchers of the repository that a new release has been made.
  • Our use case involves an automated process where we generate and deploy code automatically on a schedule.

[travi]

• However with comments, we are looking to be notified as watchers of the repository that a new release has been made

does gitlab not have a way to subscribe to release notifications? github has this ability natively. this feels more like a gitlab feature request than something that semantic-release should be responsible for

• Our use case involves an automated process where we generate and deploy code automatically on a schedule

could you expand on how this involves semantic-release? semantic-release is specifically intended to encourage continuous deployment style workflows rather than schedule based releases. with your mention of using a combination of trunk-based development and semantic-release, it is unclear to me how scheduled releases fit in.

[akashgupta88]

@travi going into a bit more detail with our workflow:

• The code generation is scheduled, not the release itself.
• Codegen can also be triggered at anytime.
• We generate some unified data models in multiple languages for being used in different platforms.
• Generated code gets pushed to master in the repo on which semantic-release gets triggered as part of a pipeline.

Part of the workflow which I have not mentioned till now:

• Codegen happens based on some changes made in another repository.
• Anyone in our entire department can make these changes.
• When a specific person changes these "definitions", the generated code commit actually is configured with the same person as author.
• So if we were able to push the comment on the same commit, the person would get an email via Gitlab as well, thus being notified of the release being made without having to explicitly subscribe to release notifications.

I know its a really niche use case. Do you think it still makes sense to have this feature as additional with opt-in?
Probably this will not get prioritized as an important feature for active development.
I could help contribute here, if it is agreed to be of value for this library.