Added build and integration testing workflows

[choukit]

This change adds workflow for building the library on pull request submission and running the integration tests. The workflow would be triggered to check for any regression on PR submission only if the PR submission has been approved by the admin.

Description of changes:

Added a build(build.yml) workflow which gets triggered on PR submission. This workflow builds the library and runs the unit tests. Along with it, it also creates and uploads the artifacts which would be used by the integ test workflow.

Added an integration tests workflow(integration-tests.yml) which gets triggered on successful completion of build workflow. This workflow downloads the build artifact uploaded in the build workflow and runs integration tests on them.

Testing done:

Tested the workflow triggers on the forked repository and verified that the corresponding workflows get triggered

Merge Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.

General

• [x] I have read the CONTRIBUTING doc
• [x] I certify that the changes I am introducing will be backword compatible
• [x] I used the commit message format described in CONTRIBUTING doc

Tests

• [ ] I have added tests that prove my fix is effective or that my feature works (if appropriate)
• [ ] I have added unit and/or integration tests as appropriate to ensure backward compatibility of the changes
• [x] I have verified all code in this commit are well formatted

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[choukit]

Can you help me understand how "The workflow would be triggered to check for any regression on PR submission only if the PR submission has been approved by the admin"?

Does this mean if any of us has to approve the PR first. Is it possible that such a workflow would be misused by any of the forked github repo created by any user?

Github workflows support approvals. The approval here means the approval for running the workflow. Consider the following sequence for better understanding

1. A contributor who is not Admin raises a PR from a forked
2. Admin opens the PR page and see a button to approve the workflow run
3. Admin verifies that the PR request is genuine and approves the workflow run
4. workflow runs

So workflow can not be misused as it can not run without Admin approval. Additionally if the user attempts to run it on forked repo or outside of the original repo, it won't be able to run anything against the AWS account. The role is stored in gtihub secrets which is not accessible to the forked repo

[choukit]

See https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks for more details