ci: enhance pull_request workflow

[Abhinandan-Purkait]

Workflow in detail

1. A user creates a PR to develop or release/x.y branch.
2. The concerned GitHub action workflow kicks in on the PR.
3. First, it checks out and sets up the runner.
4. It then runs the lint. Shellcheck and helm lint.
5. Verify the chart version, it should be of the format x.y+1.0-develop. If it’s anything else, the workflow fails. From now on any change to the helm chart in the PR would not need a helm version change. Users are not supposed to change the chart version in their PRs, even if it’s a helm change.
6. Extract the chart version from the chart. This tag would be used for building the image locally.
7. Build the images using the code in the branch and tag it with x.y+1.0-develop
8. Set up the minikube cluster.
9. Execute the CI tests by installing the helm chart from the deploy/helm/charts directory. Set the image pull policy to Never since we are supposed to use the images built in the previous step.
10. Execute the CI tests. We are to use the helm chart here.
11. If the test passes the CI succeeds else it fails.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.53%. Comparing base (1c29ecd) to head (c627be5).
Report is 1 commits behind head on develop.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop     #557   +/-   ##
========================================
  Coverage    99.53%   99.53%           
========================================
  Files            1        1           
  Lines          431      431           
========================================
  Hits           429      429           
  Misses           1        1           
  Partials         1        1           

Flag	Coverage Δ
bddtests	99.53% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pchandra19]

Verify the chart version, it should be of the format x.y+1.0-develop. If it’s anything else, the workflow fails. From now on any change to the helm chart in the PR would not need a helm version change. Users are not supposed to change the chart version in their PRs, even if it’s a helm change.

Just a few question on above : You mentioned the format should be "x.y+1.0-develop"
a) That means we will not be releasing any patch versions ?
b) Why do we have to even increment y (y+1) ?

[Abhinandan-Purkait]

Just a few question on above : You mentioned the format should be "x.y+1.0-develop"
a) That means we will not be releasing any patch versions ?

Yes we would be releasing patch versions.

b) Why do we have to even increment y (y+1) ?

Once a release is made, develop becomes the vNext. The patch releases are done from release/x.y branches. Now whenever a release let's say x.y.z is made, the develop would now become x.y+1-develop because we are working towards bumping the minor version and the release/x.y becomes x.y.z+1-prerelease because in release/x.y we are working towards bumping a patch version.

[niladrih]

The chart-release workflow might run as soon as this PR is merged, due to the helm chart change. We might want to disable that workflow. Temporarily removing the on YAML body (with a comment) could be enough.

[Abhinandan-Purkait]

The chart-release workflow might run as soon as this PR is merged, due to the helm chart change. We might want to disable that workflow. Temporarily removing the on YAML body (with a comment) could be enough.

Done. Also wondering would it be a good idea to disable the build.yml workflow.

[niladrih]

The chart-release workflow might run as soon as this PR is merged, due to the helm chart change. We might want to disable that workflow. Temporarily removing the on YAML body (with a comment) could be enough.

Done. Also wondering would it be a good idea to disable the build.yml workflow.

IMO we should let the build workflow run because there's WIP PRs and contributions coming in and contributors might want to work with their built develop branch images.