The logging part to make homer production ready requires some documentation.
The code for logging is here

When using the docker image internally at my company, the GITLAB_URL does not seem to load properly.

Steps to reproduce on internal Gitlab:

• Pull image from GitHub and build another one in internal Gitlab.
• Run the image on Gitlab pipeline with all env variables set.

An error in log mentioning Environment variable GITLAB_URL not found

• Change engine here https://github.com/ManoManoTech/homer/blob/main/package.json#L19
• Test with node v20 (should work regarding the changelog)
• Fix if needed
• Update documentation https://github.com/ManoManoTech/homer?tab=readme-ov-file#3-prerequisites

What

In the current Manomano internal project, homer offers the option of publishing and displaying a project's change log using the following commands :

• /homer changelog Generate changelogs for any Gitlab project using release tags.
• /homer release Create a Gitlab release.
• /homer release cancel Cancel a Gitlab release.
• /homer release end End a Gitlab release.

These functionalities should be reviewed and modified to make them available in the open-source project.

How

In order to add a releasable project, an internal configuration file must be modified. This behaviour needs to be reviewed to simplify the process and avoid the need to redeploy homer each time.

Firstly, we should externalise this configuration, and write documentation about it.
Then we could add a command like /homer release enable to register a new releaseable project.

The current configuration is as follows:

{
    notificationChannelIds: [
      IT_DEPLOY_CHANNEL_ID,
      FT_SELLER_CHANNEL_ID,
    ],
    projectId: 1,
    releaseChannelId: FT_SELLER_CHANNEL_ID,
    releaseManager: defaultReleaseManager,
    releaseTagManager: semanticReleaseTagManager,
  },

projectId : Gitlab project ID
notificationChannelIds : ID of the Slack channels that receive notifications about the release
releaseChannelId : ID of the slack channel where the release of the project is enabled
releaseManager : change depending on the type of the project (library, micro-service, frontend ..)
releaseTagManager : defines the tag naming (semantic, stable date ...)

The modal could be like this :

Not sure how feasible this is, but it might be nice to be able to generate a calendar (an ICS file) of the releases.

I've stumbled upon this project today and was wondering: wouldn't it be possible to implement mechanism for drawing reviewers? In larger teams it would be great if every member was involved at similar level, so this should draw reviewers considering review history and current activity. But MVP would be just ability to run command that would draw expected amount of reviewers.

List of users available for review should be configurable per project, as I don't see any reliable way based on available data (Slack channel's participant, Gitlab project's members would most probably be much wider than people interested in the MR), maybe CODEOWNERS would be closest.

What do you think?

Here is an example on how to do so: https://github.com/doctrine/collections/blob/2.2.x/.github/dependabot.yml

In the prerequisites you are talking about node 18.
Can we use a newer version of node?

Currently
The rule is an exact match.

For example if the gitlab username is [email protected] it will try to find a slack user based exactly on this criteria. In some organization the conventions can be quite different between slack and gitlab.

Expected

This rule could be tweaked according to your need

The database name is hardcoded.

How to fix:

• Use an environment variable instead.

Error message Failed to to fetch slack user with emails *** is displayed because it's hardcoded.
Line code

I can open an MR if you want