Original link: https://xuanwo.io/reports/2022-26/
Iteration 16 runs for two weeks from June 18th to July 3rd. There are many interesting things in this cycle, among which the most impressive is the experience of dumb English speaking for the first time.
Interview with Mergify
Mergify is a Pull Request automation tool. The main functions include Auto Merge, Merge Queue, PR Actions, etc. Databend first used him to solve the problem of PR automatic merging, and then gradually expanded the scope of use. Now all PR-related automation processes have been handed over to Mergify.
We use Merfigy to do the following:
- Auto Merge & Merge Queue automatically updates PRs to ensure that all PRs run tests based on the main branch before merging
- Ask the author to make changes when there is a conflict
- Check the PR’s title and content for compliance and request the author to revise it
- Automatically add corresponding tags based on semantic PR titles for use in generating Release Note
For detailed configuration, see mergeify.yml
Later, at the invitation of Mergify, I participated in an English interview with Mergify colleagues. It was the first time in my life that I participated in this kind of interview in pure English, and I felt very nervous. Mergify sent me a list of questions. I prepared a lot of time for the list of questions in advance. I took the attitude of memorizing English texts in high school and memorized all the answers. To prevent embarrassment, I also read every sentence with Google Translate to avoid mispronunciation.
When it came time to interview, I felt the same way, 233333.
Opposite is a Frenchman, who also has his own accent. We chatted a little at first, and when she mentioned that I was in China, she shared her travel experience in China with great interest. She has been to a lot of places, including Beijing, Chengdu, Shanghai, etc. It feels very interesting. Afterwards, it felt more natural. Basically, I asked and answered questions according to the outline. I also played a lot temporarily. In the end, the interview ended with laughter and laughter.
A few thoughts from this interview:
- Thanks to my girlfriend who has been pulling me to watch British and American dramas, I feel that my speech is not so rigid.
- Whether or not you can understand is someone else’s business, and whether you can open your mouth or not is your own business. As long as you dare to say it, most of the problems are solved. Grammar, pronunciation, and articulation are all small problems. No one will be idle to correct your pronunciation problems in real oral communication.
- I feel that voice communication is very interesting, and I hope to participate in more similar talk shows in the future, so as to avoid the deterioration of my language communication ability at home for a long time.
Fusebot retires
Databend has used fusebot in the past for various automations such as Nightly Release, Auto Label and Auto Merge. But maintaining such an automated bot is tedious: easy things can be done without it, troublesome things are laborious to implement. So then we decided to use off-the-shelf SaaS services as much as possible to solve these needs, instead of reinventing the wheel. As mentioned earlier, Merfigy has gradually replaced the functionality of fusebot, and is only one Nightly Release auto-created away from a complete replacement.
In order to improve the entire Release process, I launched proposal: Semantic Release . There are two main changes:
- The introduction of Semantic PR requires that the title of the PR must meet the semantic requirements (in the past, we required developers to fill in the relevant items in the description of the PR)
- Use Github’s native Release Notes generation mechanism to remove the dependency on Fusebot
Semantic PR is basically the PR version of Conventional Commits . We use Merfigy’s PR Action to enforce that developers must use legal PR types. If it does not meet the requirements, Merfigy will comment PR to request changes:
On this basis, Merfigy can automatically add corresponding tags to PRs. Then you can use Github’s native Release Notes generation mechanism to configure, just add a configuration .github/release.yml
changelog : exclude : labels : - pr-chore authors : - Mergify categories : - title : Exciting New Features ✨ labels : - pr-feature - title : Thoughtful Bug Fix ? labels : - pr-bugfix - title : Code Refactor ? labels : - pr-refactor - title : Build/Testing/CI Infra Changes ? labels : - pr-build - title : Documentation ? labels : - pr-doc
Here are some more tips about gh
: Checking the latest release and creating release-related actions are not very useful, we can use the gh
command that comes with the runner.
Get the latest release tag (note that it is different from the output of git tag)
- name : Get latest tag id : get-latest-tag run : | echo "::set-output name=tag::`gh release list -L 1 | cut -f 1`" env : GH_TOKEN : $
Create release:
- name : Create github release if not exist # Reference: https://cli.github.com/manual/gh_release_create run : | echo "Create a release for $" gh release create $ --generate-notes -p env : GH_TOKEN : $
--generate-notes
is used to let Github automatically generate Release Notes-
-p
is used to mark the current release asprerelease
Subsequent uploads only need to use the same tag:
- name : Update release to github shell : bash # Reference: https://cli.github.com/manual/gh_release_upload run : gh release upload $ databend-$-$.* --clobber env : GH_TOKEN : $
Using gh
directly is much more convenient than introducing a bunch of acitons. For the complete workflow, seedatabend-release.yml .
These are the more interesting things in this cycle, see you next week~
This article is reproduced from: https://xuanwo.io/reports/2022-26/
This site is for inclusion only, and the copyright belongs to the original author.