Release Management

[dwdraju]

Github actions will be used for both docker build and deployment. The deployment of docker image will be done by self-hosted runner to enable deployment into our internal network without opening SSH port publicly. Github actions logs and steps can be seen from Actions tab of the repo.

1. Build: This step includes building a docker image and sending the image to a registry. The image will have the module name and short commit SHA(7 character) so that the image can be separated for each build and makes it easier even for rollback. Also, the image will have latest tag to make it easier for pulling latest image for using cache to fasten build process.

2. Deployment: The deployment of docker images are done via self-hosted Github Actions Runner on our own internal instances. The self-hosted runner picks the job from github and runs the deployment script on the target instance.

3. Variables: Secret and non-secret variables like deploy host, docker registry repo & token will be stored on Github secret variables.

Versioning and deploy artifact

We use semantic versioning strategy for Github tag and release.
TODO:

1. Discuss on tag and release creation trigger
2. What are the artifacts to deploy(partial or all)
3. Manual or automated based on merge
4. Changelog maintenance

Automated Tag Bump

We use Github Actions for bumping the semantic versioning after certain actions.

[bbist]

@dwdraju,
This thread will include things mostly related to build/deploy and test automation, including running different actions on different triggers (push, pr, nightly, etc). The formal discussion on branch management, such as branch naming, branch permissions, ways to create pull requests, can be found here: #87

[dwdraju]

Icon release and tagging with manual inputs(IDEA): https://github.com/icon-project/icon-release/blob/master/.github/workflows/release_packages.yaml

[CyrusVorwald]

Changesets is a pretty robust way of doing this, although it may only be for Javascript

[andrii-kl]

@dwdraju Let's rename the current discussion title. Current name misleading a bit.

The first and second points are more about e2e tests.

The first point is not about general project building process. We don't use docker images or provision for general build. (It's looks more about e2e flow.

I would move out the third point into separate discussion.
Bump project version automatically after each merge to the main branch I think is not a good approach.

There are some disadvantages in this approach:

• We lose control over the project version. As a result, to make some particular project version you need to implement some manual control.

• We will have a lot of transition versions without artifacts, because of fixes or adding some changes to the main branch. As a result of that we can't create a task that will create and publish project artifacts.

[andrii-kl]

I would name this discussion E2E github actions workflow.

[dwdraju]

Refactored the discussion to include only the release process and deployment based build & serve strategy. @andrii-kl , can you please review once? Thanks!

[andrii-kl]

For me this discussion description is still not clear

If you don't want to change the name, and this discussion is about a common build process that we have in the build.yml file.

1. What the docker image do you want to build?
   Based on what?
   bmc / bts / bmr or something else?

2. When this Build process should start? What the trigger?

3. Does Build and deployment has any connection?
   (if not) What the trigger of the deploy process?

4. What artifacts do you want to get as a result of the deploy?

[andrii-kl]

Variables is a third option in your list. Is it a task like Build and Deployment?