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.

[grzesuav]

hi @AmitKumarDas , maybe we can push this further ? We need to :

• tag release 1.0.0 manually
• add commit verificator (to check commit prefixes)

and then I can add semantic release (and automate relasign basing on it)

[AmitKumarDas]

Hi @grzesuav Do we need to first tag a 1.0.0 & then add the commit verification?

Do you have in mind any commit verificator that can be added to this repo right away? I can add the same or even accept any PR?

I shall do the manual release of 1.0.0 shortly. cc @luisdavim do you have any reservations on tagging.

[grzesuav]

Probably can add commit verification earlier, could try

[luisdavim]

We should also start publishing the helm chart to https://hub.helm.sh/ using the same version as the docker tag.

[grzesuav]

Initial config https://github.com/AmitKumarDas/metac/pull/104

[grzesuav]

@luisdavim yes, version should be sourced from git-tag. Release in semantic-release trigger new tag, which pushes docker image and helm chart release. Not sure @AmitKumarDas you are also publishing go package somewhere ?

[grzesuav]

after merging (or before) one of the maintainers should install https://github.com/apps/semantic-pull-requests - @AmitKumarDas can you do it ?

Configuration (types - like feat/fix/chore/etc) can be adjusted later (I will try to add semantic-release and config in one go)

[grzesuav]

For semantic release itself, it can be done via :

• github action (like https://github.com/marketplace/actions/action-for-semantic-release)
• travis ci

what is your preference ?

[AmitKumarDas]

For semantic release itself, it can be done via : github action (like https://github.com/marketplace/actions/action-for-semantic-release) travis ci what is your preference ?

Let us try with github actions. I have added NPM_TOKEN & GITHUB_TOKEN as personal access tokens. However, I am not sure of the level of access that needs to be granted.

[AmitKumarDas]

after merging (or before) one of the maintainers should install https://github.com/apps/semantic-pull-> requests - @AmitKumarDas can you do it ?

Done with merge as well as installing above app!

[grzesuav]

@AmitKumarDas https://github.com/AmitKumarDas/metac/pull/105

so seems working

[grzesuav]

I have played a bit, amending commit and editing PR title to semantic form makes it unblock the PR

[grzesuav]

https://github.com/AmitKumarDas/metac/pull/109

[grzesuav]

hi, example config there (and result of running on my fork). some remarks :

1. every push to master will trigger a release
2. currently tests are run on travis and independently github action triggers a release. Therefore master could fail and release could be trigered. Mitigation needed.
3. release creates tag. Need to add triggering a docker build on tag. @AmitKumarDas how it is done currently ? I would imagine another github action can be added on tag to trigger releasing a docker image with correct version
4. build artifacts - are they any ? Should we publish something when triggering a release, a binary or sth ? [I would imagine it would be useful]
5. having changelog plugin would allow to have CHANGELOG.MD file (name could be customized) maintanable

any other suggestions ?

[grzesuav]

around 2. - possible solutions :

• wrap running travis ci into workflow and trigger release on master only when travis ci passed
• run tests as github action (without using travis)
• run semantic-release from travis (requires additional travis setup - on master branch when tests pass trigger release)

[grzesuav]

around 3.

• I see advantages of keeping whole CI in one place , looking at https://quay.io/repository/amitkumardas/metac?tab=tags it creates a lot of versions

[AmitKumarDas]

@grzesuav Any CI or github actions that makes the entire workflow smooth will be good. I would need help from your side to setup these.

Travis CI is used to check if integration test, unit test & docker image build is actually passing. Quay is setup from my own repository/login after integrating it with metac repo. Quay triggers build for every PR & merge to metac. Release is a manual tagging process that asks for a release version & upon setting triggers a build which in turn triggers Travis & Quay.