GHA: Azure Integration Tests #726
Conversation
csegarragonz
force-pushed
the
azure-gha
branch
7 times, most recently
from
f4055e0
to
6565cb2
Compare
csegarragonz
changed the title
csegarragonz
force-pushed
the
azure-gha
branch
6 times, most recently
from
b7b6128
to
7edaf4f
Compare
.env
Outdated
| FAASM_VERSION=0.9.2 | ||
| FAASM_CLI_IMAGE=faasm/cli:0.9.2 | ||
| FAASM_WORKER_IMAGE=faasm/worker:0.9.2 | ||
| FAASM_VERSION=0.9.3 |
There was a problem hiding this comment.
I tag a new release to fix the errors in k8s files that the integration tests uncovered.
| @@ -11,8 +11,51 @@ defaults: | |||
| shell: bash | |||
There was a problem hiding this comment.
The reason this file appears as modified, and not as new, is because in order to test a workflow that is triggered on workflow_dispatch, the workflow needs to already be registered on the default branch.
Thus, I merged in two very simple PRs (#725, #727) to add the skeleton of this file and the next one.
csegarragonz
force-pushed
the
azure-gha
branch
2 times, most recently
from
3d685dd
to
b11687c
Compare
| if: always() | ||
| run: ./bin/inv_wrapper.sh cluster.delete --name ${{ env.CLUSTER_NAME }} | ||
| working-directory: ${{ github.workspace }}/experiment-base | ||
| - name: "Chown all files" |
There was a problem hiding this comment.
This is necessary to ensure that consecutive runs on the same runner can clean the state (i.e. remove all files). Otherwise, some docker-generated files may be root-owned.
.github/workflows/sgx_hw.yml
Outdated
| ./bin/inv_wrapper.sh vm.run-command \ | ||
| --name ${{ env.VM_NAME }} \ | ||
| --path "code/faasm" \ | ||
| --cmd "sudo rm -rf ./clients/cpp/venv && docker compose exec cpp ./bin/inv_wrapper.sh func.local libfake" |
There was a problem hiding this comment.
We remove the ./venv's to force their re-creation with the first call to ./bin/inv_wrapper.sh, and to avoid possible inconsitencies between the new commits and the docker images.
csegarragonz
force-pushed
the
azure-gha
branch
4 times, most recently
from
085a88e
to
10ab154
Compare
|
@Shillaker I agree with you that running on every commit to main may be a bit too much. I am also reluctant to run them on a cron schedule. For the moment, and while I think about it more, I will merge in this PR with both workflows enabled only on Another option (which I include for reference) is to apply filters on the files modified in the PR, and only trigger the workflow when certain files are modified ( I am not sure what you mean with a tag to the commit message. Do you mean creating a git tag (e.g. |
In this PR I add two workflows that run some tests on a production environment on Azure.
The first workflow runs the
demo/hellofunction on a managed Kuberenetes cluster in AKS. It is only triggered onworkflow_dispatch, which means that we need to navigate to the "Actions" tab, click on the workflow name (Azure Integration Tests), and click on the "Run workflow" button. The workflow could be improved in several ways:mainbranch. (The risk with this one is knowing when the images for the new tag will be ready to be pulled).mainbranch (even though noticeable changes will only happen once we release a new tag).The second workflow runs the tests on an SGX-enabled Azure VM in hardware mode. It is triggered on
workflow_dispatchand when a commit is pushed to themainbranch (i.e. when a PR is merged in). This trigger behaviour aims to strike a compromise between not too often triggering yet often enough to catch regressions. Note that this action also provisions a fresh VM and installs Faasm from scratch, what also has helped flushing out installation issues.To make it easier to access our Azure subscription without poluting the organisation's secrets, these workflows run on a
self-hostedrunner where we have already ranaz login.NB: Some of the SGX tests in Hardware mode are actually failing. I implement a plethora of fixes in #686, so rather than cherry-picking changes to make the tests pass here, I'd rather fix all SGX issues in #686.