Using GitHub actions for automatic version Publishing


Configure semantic release action

Semantic release action is a GitHub action that runs semantic release

usage method

Step 1: set the configuration file of semantic release in your warehouse. If not, the default configuration of semantic release will be used

Step 2: add secrets for semantic release authentication in your GitHub repository to ensure normal permissions

Using GitHub actions for automatic version Publishing

GITHUB_TOKENNo need to add, generated by GitHub by default. If you want to publish to NPM, you need to add it manuallyNPM_TOKENTo the secrets list

Step 3: add a workflow file to your warehouse to create a custom automated process.

  • Semantic release action supports the following inputs:

    • branch: [optional] set which branch to publish on. It will override the branch property in your profile. If this property is not configured here or in your configuration file, the master branch will be used for publishing by default
    • semantic_version: [optional] specifies the semantic release version range to use
    • extra_plugins[optional] it is used to pre install additional semantic release plug-ins, and the version range of plug-ins can be specified
    • dry_run: [optional] indry-runRun semantic publishing in mode, which will override the dryrun attribute in your configuration file
  • Semantic release action supports the output of the following variables (if you need to use an output variable, you need to assign an ID to your task in advance. See the following advanced example)

    • new_release_published: whether a new version has been released, return totrueperhapsfalse
    • new_release_version: the version number of the new version
    • new_release_major_version: major version number of the new version
    • new_release_minor_version: minor version number of the new version
    • new_release_patch_version: the patch version number of the new version

A simple example

  - name: Semantic Release
    uses: cycjimmy/[email protected]
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

An advanced example

  - name: Semantic Release
    uses: cycjimmy/[email protected]
    ID: semantic? You need an 'ID' to use the output variable
      branch: master
      semantic_version: 15.13.28
      #Here, you can specify the version range or not for the semantic release plug-in
      extra_plugins: |
        @semantic-release/[email protected]
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
  - name: Do something when a new release published
    if: steps.semantic.outputs.new_release_published == 'true'
    run: ...

Using semantic release in old warehouse

Manually tag the last released version
For example, the publish branch ismaster, the last released version was1.1.0, the submission Sha value of this version is1234567To confirm that the submission has been typedv1.1.0Label for

# Make sure the commit 1234567 is in the release branch history
$ git branch --contains 1234567

# If the commit is not in the branch history it means that either:
# - you use a different branch than the one your release from before
# - or the commit sha has been rewritten (with git rebase)
# In both cases you need to configure your repository to have the last release commit in the history of the release branch

# List the tags for the commit 1234567
$ git tag --contains 1234567

# If v1.1.0 is not in the list you add it with
$ git tag v1.1.0 1234567
$ git push origin v1.1.0

Code submission specification

Using commit


$ npm install -g commitizen cz-conventional-changelog

Global configuration, create a.czrcThe file is in your pockethomeDirectory, and thepathPoint to the commit adapter installed above to support the commit message format of angular

$ echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc

For project level configuration, run the following command in the project directory

$ commitizen init cz-conventional-changelog --save --save-exact

Use the following command insteadgit commit -mcommand

$ git cz

After configuring commit, the new process is as follows:

#Pull update in advance
$ git pull

#After development and modification, GIT add
$ git add .

#Submission code
$ git cz

#Push code
$ git push

Commit message format

<type>(<scope>): <subject>
< blank line >
< blank line >
  • <type>

    • feat: new features
    • fix: fix bugs
    • docs: documentation
    • style: format (changes that do not affect code operation)
    • refactor: refactoring (i.e. not a new feature, not a code change to modify a bug)
    • perf: change code to improve performance
    • test: add test
    • choreChange of construction process or auxiliary tools
  • <scope>: optional item to indicate the scope of the impact of this submission, e.g$location, $browser. You can use the*
  • <subject>: used to briefly describe this change, try to follow:

    • Start with a verb, use the first person present tense, for examplechangeInstead ofchangedorchanges
    • Don’t capitalize the first letter
    • There is no full stop at the end.
  • <body>: Yes<subject>Description of
  • <footer>: Main placementIncompatible changesandClose issueInformation on

    • Incompatible changes: withBREAKING CHANGE: At the beginning, describe the change, the reason of change and the method of transfer.
    • Close issue: for exampleclose #123

Special format

  • Revert: in addition, if the previous commit needs to be revoked, the commit message must be in therevert:At the beginning, followed by the previous descriptionHeaderPart, the format remains unchanged. And,<body>The format of part is also fixed, and the Sha value of commit before revocation must be recorded.

Here are some examples of submissions

feat($browser): onUrlChange event (popstate/hashchange/polling)

Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available

Breaks $browser.onHashChange, which was removed (use onUrlChange instead)
feat(directive): ng:disabled, ng:checked, ng:multiple, ng:readonly, ng:selected

New directives for proper binding these attributes in older browsers (IE).
Added coresponding description, live examples and e2e tests.

Closes #351
feat($compile): simplify isolate scope bindings

Changed the isolate scope binding options to:
  - @attr - attribute binding (including interpolation)
  - =model - by-directional model binding
  - &expr - expression execution binding

This change simplifies the terminology as well as
number of choices available to the developer. It
also supports local name aliasing from the parent.

BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.

To migrate the code follow the example below:


scope: {
  myAttr: 'attribute',
  myBind: 'bind',
  myExpression: 'expression',
  myEval: 'evaluate',
  myAccessor: 'accessor'


scope: {
  myAttr: '@',
  myBind: '@',
  myExpression: '&',
  // myEval - usually not useful, but in cases where the expression is assignable, you can use '='
  myAccessor: '=' // in directive's template change myAccessor() to myAccessor

The removed `inject` wasn't generaly useful for directives so there should be no code using it.
fix($compile): couple of unit tests for IE9

Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.

Closes #392
Breaks api, foo.baz should be used instead
fix(package): update read-pkg-up to version 7.0.0
fix: clarify message for EGITNOPERMISSION error
docs(guide): updated fixed docs from Google Docs

Couple of typos fixed:
- indentation
- batchLogbatchLog -> batchLog
- start periodic checking
- missing brace
docs: fix grammar
docs: corrections and further clarifications 
docs: update broken link
docs(README): update version number
docs(README): place badge
docs(inputs): remove redundant defaults
style: fix table indentation
style($location): add couple of missing semi colons
refactor: remove unnecessary object destructuring
refactor: use `Object.entries` rather than `Object.keys`
perf(*): Update network configuration
test: clarify variables name
test(testRelease): set schedule test
chore(package): update xo to version 0.25.0
chore(package): remove commitizen from our dependencies
chore(*): transfer repo to cycjimmy
revert: "fix: do not convert ssh `repositoryUrl` to https"

This reverts commit b895231.

Related documents

  • semantic-release-action
  • Guide for writing commit message and change log

Link to the original article:

Recommended Today

Do you know the constructor in JavaScript?

Background analysis How to define multiple objects with the same structure (for example, the same attribute name and different attribute values)? For example: var p1={x:10,y:20} var p2={x:30,y:40} var p3={x:50,y:60} In the above code, if there are many attributes, we need to write the attributes repeatedly when building the object, the amount of code repetition is […]