I use prerelease tags when I deploy to stage, and normal tags when deploying to production.
In my releases I only want the normal tags to be there, and the changelog should also consider the last normal tag and ignore any prerelease tags.

Eg.

• release v1.0.0
• prerelease v1.1.0-0 (ignored)
• prerelease v1.1.0-1 (ignored)
• release v1.1.0

And changelog should generated should be b/w v1.0.0 and v1.1.0

Hi. I would like to use your tool in private gitlab instance. Could you add variable for configure it in docker run command?

Hello.

I have found this software and it is wonderful. Thank you.
It's 2022 and Gitlab still doesn't have a button in the UI to generate the changelog automatically.

I've tested it and there seems to be a problem when creating new releases. It gives error 400 bad request.
According to the documentation, when a release is created a parameter "tag_name" (underscore) must be sent

https://docs.gitlab.com/ee/api/releases/#create-a-release

From what I can see in the code, a "tagName" parameter (camelCase) is sent and this seems to be the problem.

I have debugged the code and this is the body that is sent:

{
  "description": "some changelog text",
  "tagName": "v0.0.5"
}

Can you check to see if I'm right?
Thank you.

Perhaps it's intended behaviour, but it's not entirely clear to me based upon the docs.

Scenario

• I've merged a MR and had it auto-close the issue.
• Running the generator adds the issue to the list with the label, e.g. Enhancements.

However, the issue does not show up under Closed issues.

Do closed issues only show up when it has been closed during the release, but:

• There is no corresponding MR
• There is a corresponding MR, but issue doesn't have any of the mentioned labels

FYI there's activity on the original repo to finally finish the GitLab integration

Hi,

I would also like to thank you for this great tool!

I would like to ask, do you guys suffer from having in the Release Notes Merge Requests that do not have as a target branch this branch that is specified as the parameter TARGET_BRANCH(for instance, 'master')? Like it is mentioned in the "How it works" section, today in the release notes are added Merge Requests within the time range defined by the last two tags. However, within this time range can be merged Merge Requests to different branches, and the issue is that in the Release Notes go all of the MRs and not only the one merged into TARGET_BRANCH.

This brings confusion, because I use the tool for the 'master' branch, but we have 'feature branches' for features that are under development and when we release in master, then in the Release Notes are displayed MRs from the feature branches which are not released actually.

Thanks

Currently, if you want to close an issue without implementing anything, there's no way to exclude it from the release notes. This could happen if you just want to resolve an issue as not a bug, non reproducible, not going to implement, etc.

The only way to do this seems to be to delete the issue, which will of course not retain any information about the issue.

One possible solution would be to add the ability to filter issues marked with a certain label from the results.

Hi!
Thank you for this library! It's been really useful for us.

I have a quick question: is there a reason to use updated_at (updated_after / updater_before) for issues and MRs? In our case MR gets updated after it gets merged and sometimes the same MR appears on two consecutive releases. Any idea what could be the problem?

Hello,

We are occasionally getting the following error: TypeError: issue.labels is not iterable. It's rather tricky, since the API returns an empty list for issues which have no labels, so iteration should not be a problem.

Do you by chance know what could cause this?

Hi! I'm testing your tool and I've noticed something strange - the last merged merge request didn't appear in release notes. Here my gitlab-ci.yaml

stages:
  - deploy
  - post_deploy

tag-after-deployment:
  only:
    refs:
      - master
      - develop
  except:
    refs:
      - tags
  stage: deploy
  image: debian:stable
  before_script:
    - source environments/lab/make.env
    - apt-get clean -qq
    - apt-get update -qq --fix-missing
    - apt-get install -qq --fix-missing jq git
    - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
    - eval $(ssh-agent -s)
    - echo "${SSH_PRIVATE_KEY}" | tr -d '\r' | ssh-add - > /dev/null
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - ssh-keyscan git-stage.nordigy.ru >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
    - export VERSION=$DOCKER_TAG
    - git config --global user.name "${GITLAB_USER_NAME}"
    - git config --global user.email "${GITLAB_USER_EMAIL}"
    - git config -l
    - git remote set-url origin "[email protected]:contact-center/integrations/devops/environments/engage-digital.git"
    - git remote -v
  script:
    - git tag -af "${VERSION}" ${CI_COMMIT_SHA} -m "${VERSION}"
    - git push origin --tags -f

generate-release-note:
  only:
    refs:
      - tags
  stage: post_deploy
  image: docker:18-git
  services:
    - docker:18-dind
  script:
    - docker container run -e GITLAB_PERSONAL_TOKEN=${GITLAB_ACCESS_TOKEN} -e GITLAB_API_ENDPOINT="https://git-stage.nordigy.ru/api/v4" -e GITLAB_PROJECT_ID=${CI_PROJECT_ID} 00freezy00/gitlab-release-note-generator

I compared commits SHA and they are the same in pipeline and in tag.

Hello,

First of all thanks for this amazing tool.

It it possible to generate a release note with only merge requests? There are any flag to disable issues?

And how can I download the output file, for example using an artifact in CD, because at this moment I have to open the pipeline, check the step output and copy/paste the content to a file.

Thanks

I would like to be able to add a new label to issues that are added to release notes, ie 'Deployed'

The easiest place would be in issue.js searchIssuesByProjectIdStateStartDateAndEndDate but that seems to be outside the scope of that function.

I'll be glad to submit a PR if you can give me some direction on how you would like it done.

As part of our release process we would like to be able to pull a list of issues that would be included in the next release. This would pull the same release notes but not write them to a tag, I guess the tag would not have to exist so we would need to pull all closed issues since the previous tag until an end date of now.

I'll be glad to submit a PR if you can give me some direction/comments.

When i try to generate a Changelog for a Tag that has more than 20 issues closed i just get 20 issues.

From the code i would say its the pagination from gitlab that limits the Request when fetching issues.

https://docs.gitlab.com/ee/api/README.html#pagination

if you add per_page=100 the limit would be increased to 100 issues which should be fine for most people