Automate Releases

[dennyabrain]

1. Figure out how to automate creation of new releases following semantic versioniong
2. Figure out how to add documentation automatically in the release notes by combining commit messages
3. Find out how to add semantic version number to python and node projects automatically

[dennyabrain]

To elaborate on task 3. I would like our backend and frontend code to be able to show to the user, which version or github commit they are running. So it will involve some kind of automation to be run everytime a user pushes to master or dev branch. This automation should update a packager version (for npm projects) and some other text file (for flask) that the backend or frontend code has access to. The backend/frontend code should then expose these values somehow. For backend servers, i can imagine making these part of the payload of the /health endpoint. For frontend, we could visually show it on the footer or a /info page

[d80ep08th]

Automate using Github Workflow

In a fresh new repository with a readme

There is a github Actions tab

When you click on Actions, this page opens up

You will get this page when you click on set up a workflow yourself link

main.yml file explained

An event is any git command such as git pull or git push . Events ===> Workflows ===> Actions Events will trigger workflows which will refer the actions and do them for the specific repo. A runner will be the operating system on which the workflow runs.

Add the following snippet of code to the main.yml file

      - name: Conventional Changelog Action
        id: changelog
        uses: TriPSs/conventional-changelog-action@v3
        with:
          github-token: ${{ secrets.github_token }}

      - name: Create Release
        uses: actions/create-release@v1
        if: ${{ steps.changelog.outputs.skipped == 'false' }}
        env:
          GITHUB_TOKEN: ${{ secrets.github_token }}
        with:
          tag_name: ${{ steps.changelog.outputs.tag }}
          release_name: ${{ steps.changelog.outputs.tag }}
          body: ${{ steps.changelog.outputs.clean_changelog }}

such that the main.yml looks like this :

the snippet added the actions required to bump the tag/version according to semantic versioning, automate the releases and changelogs

Commit the file with feat: automating releases and changelogs as the message

Once the workflow executes successfully , you should have an automated release with the change logs as show

Yes its that easy! If you go back to that actions tab , you can see the Github actions workflow of the main.yml we just set yp

If you go to the repository, you will see that there are two new files: package.json and CHANGELOG.md Our workflow checks for a package.json file and creates one if it doesn't exist. So this is efficient for npm projects.

Combining commit messages with semantic versioning and adding documentation

For this workflow, we use this actionhttps://github.com/marketplace/actions/conventional-changelog-action So with any advent of a pull or push git even, the workflow will read the commit messages. This action works according to the conventional commits specification . It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

The commit contains the following structural elements, to communicate intent to the consumers of your library:

If a tag is: [X.X.X], then the following three labels decide, how tag/versioning of release works!

1. fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning). [X.X._]

2. feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).[X._.X]

3. BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.[_.X.X]

4. types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.

5. footers other than BREAKING CHANGE: may be provided and follow a convention similar to git trailer format.

How do the commit messages work?

$ git add . && git commit -m "feat: automating releases and changelogs"
$ git push origin main
##
some work later
##
$ git add . && git commit -m "fix: this should update patch"
$ git push origin main

$ git add . && git commit -m "fix(python): jupyter notebook for python"

#some work done#

$ git add . && git commit -m "feat: added a virus"

#some work done#

$ git add . && git commit -m "feat: added bugs 
> 
> BREAKING CHANGE: partake folder is released"

$ git push origin main

[dennyabrain]

So I see that the automated release have a 2 zip files in the Assets section. Which is basically the source code compressed and saved. a task to add for future would be to figure out how to add custom files to the assets list.

For instances a repo might have an android app or chrome extension in its src/app folder. running a build command might produce a zip file for that app. It would be useful to see how that can be added to the assets list.