Use semantic release in metac

[grzesuav]

To make automatic release notes and make easier to deploy new version, semantic-release could be used. https://github.com/semantic-release/semantic-release is a tool which :

• create release notes from commit messages
• creates releases on gihub https://github.com/AmitKumarDas/metac/releases page
• version the release automatically

It would need :

• make commit messages follow some conventions (which can be problematic it they weren't any )

[grzesuav]

@AmitKumarDas I can try to add support (I have done it in my gitlab project ) probably shouldn't be hard for github.

[AmitKumarDas]

Sounds great @grzesuav

[grzesuav]

briefly looking on commit messages:

8742540 [example] update steps to automate uninstall openebs (#62)
a238880 [example] update uninstall openebs example to latest metac (#61)
4ea7d56 [gctl] add UpdateDuringPendingDelete option (#60)
9af1eb8 [example] fix example on uninstall openebs (#59)
00b8375 [example] update rbac for uninstall-openebs example (#58)
a74a6fe [fix] name of finalizer assigned to watch resource (#57)
df70117 [example] update uninstall-openebs to latest metac (#56)
ee6f735 [config] fix loading of metac config file(s) (#55)
e6c273c [example] add updated metac to clean uninstall openebs (#54)
fd7e447 [example] add example to clean uninstall openebs (#53)
c624ab1 [readme] update readme with latest info about metac (#52)
3a0c517 [select] add advanced select rules to match specific resource(s) (#51)
59073f6 [config] add wait for all metac configs to load (#50)
ea19971 [example] improved README for set-status-on-cr example (#49)
cb54722 [example] update set-status-on-cr example with README.md & test.sh (#48)
ef8f6d5 [example] update set-status-on-cr to latest metac commit (#47)
0065a1c [fix] running metac from config (#46)
89bf818 [example] update set-status-on-cr to latest metac commit (#45)
d6ba051 [fix] config load by adding path along with file name (#44)
5c9a91b [example] update set-status-on-cr to latest metac commit (#43)
1c3c1a4 [local] fix config to avoid directories (#42)
eac4e63 [example] changes to set status on cr to point to latest metac (#41)
5df534c [local] add logs to local config based metac run (#40)
768f916 [example] set status on custom resource via inline hook (#39)
7c5d651 [start] move start code from main.go to start package (#38)
e24638c add generated client code to let metac be used as a lib (#37)
b625ffc [hook] add support to invoke inline functions as hooks (#36)
fb35f12 separate selector logic for watch & attachments of gctl (#35)
31c15db add skipReconcile to GenericController hook response (#34)
873ada4 [local] add option to run metac from local config (#33)
806e3a2 Adding a notice to the README about finalizers (#31)
d910577 adding a helmchart to deploy metac (#30)
6383e2c Make client-go throttling configurable. (#29)
41435e8 (tag: v0.1.0) [usecase, gctl]: showcase install/un-install of CRD (#28)

so the closes match is https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-ember#ember-convention .

However I often find used Angular commit conventions (https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type) (at least up to types) which look likes :

chore(github): update Issue template with LTS info

I would propose the similar without the scope (int the ( ) brackets) :

chore: #555 - Update Issue template with LTS info

but it should be discussed and enforced in github checking for agreed commit messages format (like via https://github.com/probot/semantic-pull-requests or by some travis job check)

Commits up to now can be handled differently (like do not rewrite history, just map them somehow to major/minor/path/chore) and enforce format till this moment.

@AmitKumarDas any opinions on that ?

[AmitKumarDas]

chore: #555 - Update Issue template with LTS info

I guess above looks fine. I hope #555 is issue number. Issue may be optional perhaps.

Was #555 the PR number? If yes can it be at the last? I find most release use PR number at the last as a kind of suffix

[AmitKumarDas]

Can I set the old commits with GitHub labels like major, minor, chore etc. Will that do without getting too much into git stuff.

[AmitKumarDas]

@kmova can you please provide your thoughts as well.

[grzesuav]

Can I set the old commits with GitHub labels like major, minor, chore etc. Will that do without getting too much into git stuff.

No, I am afraid not. Semantic release relies only on git commit messages. Other option is to tag new release manually and enforce standards and introduce semantic release since this moment.

[grzesuav]

Moreover (https://github.com/semantic-release/semantic-release/blob/master/docs/support/FAQ.md#can-i-set-the-initial-release-version-of-my-package-to-001) they recommend to start from 1.0.0 so maybe it would be possible to manually tag a 1.0.0 with release notes etc and since then rely on commit messages ?

By the way @AmitKumarDas I have some questions :

1. Which CI is used for doing build ? I do not mean test but actually to provide binary packages/docker images
2. What are build artifacts ? Go binary/docker image ?

[kmova]

@grzesuav - thanks for bringing up these questions.

I agree we should go ahead and make a 1.0.0 release and start enforcing the commit message format.

• Regarding the commit message format, can it be:

  type(module): commit description specifying what is done #issue-number
  

  At times, a PR can be raised without an issue, so the #issue number can be optional.

• For CI, we could use travis, but open to ideas.

Also, is there a way to enforce commit message format in github?

[grzesuav]

@kmova - yes, for format message it is actually an angular message format - https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines . I would say that (scope) should be also optional - actually we only need type to make semantic-release work

for enforcing commit messages for example https://probot.github.io/apps/commitlint/

so, travis is also building go binaries and making and push image to docker registry ?

[AmitKumarDas]

@grzesuav Triggers have been set at quay to build docker images of metac whenever any PR is pushed against metac repo. These images are hosted at quay (similar to dockerhub).

One needs to use docker pull quay.io/amitkumardas/metac or quay.io/amitkumardas/metac as the image name. One can also use various tags present here

[grzesuav]

@AmitKumarDas ok, so on tag there will be tagged docker release made there ? Like quay.io/amitkumardas/metac:1.0.0 ?

[AmitKumarDas]

Yes. @grzesuav
It's the same case when we cut a GitHub release on the repo. This release version is automatically reflected as a tag in the docker image.