Automatically generate changelog-Section 3: Use release-it in combination with Drone continuous deployment tool

background

After "Automatically generate changelog-Section 1: Standard submission code" and "Automatically generate changelog-Section 2: Automatically generate" , the log can realize one-click output. For small projects that are not connected to continuous deployment, running the release-it command locally can simply implement the process of version marking, output log, and pushing git and npm, which can be said to be in place in one step. The company's project is based on the R&D process of the Drone continuous deployment tool, and the steps mentioned above need to be combined with the continuous deployment tool.

Briefly explain my current development process based on Drone:

Branch situation:

• The master branch is the branch for code aggregation, and continuous deployment is triggered after PR/MR to automatically deploy to the test service.
• The production branch is used as a production branch. After the code is pushed, continuous deployment is triggered to automatically deploy to online services.

Operation process from R&D to release:

1. Fork a copy of the code under your own name, and then develop it locally.
2. When the development needs to be tested, initiate a PR/MR and push it to the main warehouse, and the group leader or group member code review be merged into the main warehouse master branch after passing
3. Merge master to production, update the log and version number and submit the production branch for release operation

In the above process, the manual update of the version will have a relatively large risk of misoperation in the process of multi-person collaboration, so it is planned to use tools to achieve the work of automatically updating the version. This is the ultimate goal of the three sections of the "Automatically Generate Changelog" article.

The content mentioned in this article is highly bound to our company's current use of the Drone continuous delivery tool and workflow. It is not recommended to copy it mechanically. The overall reference idea is roughly the same. It is recommended to learn from it.

The following explains release-it in the continuous deployment tool Drone.

The details of the combination

The process of continuous deployment is divided into three parts: pull warehouse, build code, deploy and push. Now it is necessary to add the "version update" link in this process. The following is a reference example of drone deployment configuration:

kind: pipeline
name: releases

steps:
- name: release
  image: tarampampam/node:12.13-alpine
  environment:
    SSH_KEY:
       from_secret: ssh_key
  commands:
  - GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i $SSH_KEY"
  - git config --global user.email "[e-mail]"
  - git config --global user.name "in_boot"
  - npm ci
  - npm run build
  - npm run test:unit
  - npm run release -- --ci --no-git.requireUpstream --git.pushRepo=origin
- name: release2npm
  image: plugins/npm
  settings:
    username: in_boot
    email: [e-mail]
    password:
      from_secret: npm_password
    registry: http://self.uxfeel.com/

trigger:
  branch:
  - production
  event:
  - push

Although the code is a few lines simple, the details and ideas behind it are rather complicated and need to be mentioned in detail.

Process

release-it will do the following by default:

Git part:

• Compare the last version tag with the latest history and output the log to the log file;
• Analyze the updated version number of the log content;
• Submit content changes and mark the version label;
• Push to the remote;

npm：

• Push to npm service;

Push npm service is obviously unnecessary, here I turn off its function in the release-it configuration. But the git part encountered more problems.

problem

Encountered problem 1: No Git

When used in a continuous deployment tool, the part about Git in the first step is stuck, indicating that there is no git. Since there is no git in the official docker image provided by node, I replaced it with this image: tarampampam/node:12.13-alpine to use git.

Encountered problem 2: ssh is not authorized

How to provide credentials in the container to git push code? There are two situations where http is different from ssh:

In the case of http, write the account password in secret of Drone and use it as a system variable. Then close the git-push link of release-it, and push the git part manually to support account passwords.

  environment:
    USERNAME:
       from_secret: username
    PASSWORD:
       from_secret: password
  commands:
  - git config --global user.email "[e-mail]"
  - git config --global user.name "in_boot"
  - npm ci
  - npm run release -- --ci --no-git.requireUpstream --git.pushRepo=origin
  - git push "https://$USERNAME:$[e-mail]/file.git"
  

SSH needs to modify GIT_SSH_COMMAND (git version is higher than 2.7.0), secret of Drone, and use it as a system variable, which can be added in the GIT_SSH_COMMAND setting.

  environment:
    SSH_KEY:
       from_secret: ssh_key
  commands:
  - GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i $SSH_KEY"
  - git config --global user.email "[e-mail]"
  - git config --global user.name "in_boot"
  - npm ci
  - npm run release -- --ci --no-git.requireUpstream --git.pushRepo=origin

Encountered problem 3: Release-it prompts that the upstream branch is not set

ERROR No upstream configured for current branch.
Please set an upstream branch.
Documentation: https://git.io/release-it-git

In this case, using --no-git.requireUpstream --git.pushRepo=origin directly avoids the release-it check.

Encountered problem 4: package-lock.json file will be changed after npm install

The Git status of the package-lock.json file is changed, and the releaset-it cannot be performed. Here you can use another command of npm to solve this problem:

$ npm ci 

Users of yarn can use the following commands to achieve the same effect:

$ yarn install --frozen-lockfile

Concluding remarks

Finally, thank our front-end partners for helping me toss this set of things. Since the end of 2019, the research and development process has iterated several versions. From the beginning of git-flow to the current gitlab-flow, I never know why to use it. Continuous deployment tools to learning devops, continuous delivery and lean thinking, all the way to the present, learning and progress together. Thanks to the support of the operation and maintenance brother and the release of the technical director, I have the opportunity to deploy to the cloud and have the time and energy to execute until now.

Quote

https://stackoverflow.com/questions/29776439/username-and-password-in-command-for-git-push