Generate changelog in branch before creating a tag

GitLab CI/CD
1

I’ve been trying to get the auto changelog creator to work with my pipelines with much frustration. The examples are a bit sparse tbh.

I have a pipeline that runs the necessary steps for my repo. I also added a .pre stage that should create a changelog entry based on differences between the previous and current tag version. It looks something like this:

update-changelog:
  stage: .pre
  tags:
    - shell
  script:
    - export LATEST_VERSION=$(git describe --tags --abbrev=0)
    - export PACKAGE_VERSION=`poetry version | awk '{print $2}'`
    - |
      echo $LATEST_VERSION
      echo $PACKAGE_VERSION
    - |
    curl --header "PRIVATE-TOKEN: xxx" --data "version=$PACKAGE_VERSION&from=$LATEST_VERSION&to=$PACKAGE_VERSION&branch=dev" "https://gitlab.xxxxyyyy.com/api/v4/projects/666/repository/changelog"
  only:
    - tags
    - release

The pipeline is paused and the changelog entry is added, however, it’s not added to the tag after the pipeline continues. How can I remedy this shortcoming?

2

Hi, I’m looking for a similar answer. Have you solved your problem?

3

I solved it in another way based on this post Automatic Changelog and Versioning with GIT - Philipp Doblhofer

Create An Access Token

  • In the desired repository go to Settings→Access Tokens.

  • Give the token a name

  • Check `api` and `write-repository` for the Scopes

  • Select Maintainer for the role

  • Click `Create Project Access Token`

  • On the same page copy the newly created token. It's the last time you will be able to see it.

  • Go to Settings → CI/CD → Variables

  • Create the variable `GITLAB_TOKEN` and paste the copied token into the `Value` field

  • Mark it as `Protected` and `Masked`

  • If the main/master repository branch isn't protected yet, then set it to protected in Settings → Repository → Protected Branches

Add the following to the .gitlab-ci.yml file. Change the image to the one you’re using.

update-changelog:
    image: node:19-buster-slim
    stage: deploy
    # Expose the GITLAB_TOKEN environment variable to this job
    # as a GitLab variable to be used by semantic-release
    variables:
        GITLAB_TOKEN: $GITLAB_TOKEN
    before_script:
    - apt-get update && apt-get install -y --no-install-recommends git-core ca-certificates
    - npm install -g semantic-release @semantic-release/gitlab @semantic-release/changelog conventional-changelog-conventionalcommits @semantic-release/commit-analyzer @semantic-release/git
    script:
    - semantic-release
    only:
    - master

The image refers to the docker container. The stage sets the point in the CI/CD pipeline where the changelog creation will be executed. In the section before_script we install the necessary software components. In script we finally execute the generation.With only: master we define, that the section should just be executed, if the commit was in the main branch. We must set the variables to look for the $GITLAB_TOKEN we created, otherwise it won’t authenticate.

Creating a .releaserc File

We need to create a file in the root of the repository called .releaserc (with optional .yaml or .json extension). Here you can configure the way the changelog file gets created.

{
    "branches": ["master", "dev"],
    "plugins": [
        [
            "@semantic-release/commit-analyzer", {
                "preset": "conventionalcommits",
            }
        ],
        [
        "@semantic-release/release-notes-generator", {
                "preset": "conventionalcommits",
            }
        ],
        [
            "@semantic-release/changelog",
            {
                "changelogTitle": "# Changelog\n\nAll notable changes to this project will be documented in this file. See\n[Conventional Commits](https://conventionalcommits.org) for commit guidelines."
            }
        ],
        [
            "@semantic-release/git",
            {
                "message": "chore: Release ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
            }
        ]
    ]
}

With branches we define, which branches we’d like to generate a release. With the plugin section, we tell the tool, that commit messages should be analyzed with the conventionalcommits convention. Derived from the commit messages, it is determined, if the new release should be a Major, Minor, or just a Patch Release. The plugin release-notes-generator will generate the changelog-content. The Addon changelog is finally writing to the CHANGELOG.md file. git creates a commit with the new file. With the parameter message, you can define the commit-message. Noticeable is the text [skip ci]. With that, you can tell GitLab, to skip triggering the CI-Pipeline – because we do not want to create a new version just for the new CHANGELOG file.

Hope this helps.

4

Thanks, I’ll have a look at it

Edit :

Yeah ! It’s works well. Ty