I used this and this to create the GitHub action below:
on:
push:
branches:
- main
paths:
- 'actions/**'
jobs:
training-testing:
name: Training and Testing
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Rasa Train and Test GitHub Action
uses: RasaHQ/rasa-train-test-gha@main
with:
requirements_file: 'actions/requirements-actions.txt'
data_validate: true
rasa_train: true
cross_validation: true
rasa_test: true
test_type: all
publish_summary: true
github_token: ${{ secrets.GITHUB_TOKEN }}
- name: Upload model
if: github.ref == 'refs/heads/main'
uses: actions/upload-artifact@main
with:
name: model
path: models
build_and_deploy:
name: Build Action Server image and upgrade Rasa X deployment
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
- id: action_server
name: Build an action server with custom actions
uses: RasaHQ/action-server-gha@main
with:
actions_directory: 'actions'
requirements_file: 'actions/requirements-actions.txt'
docker_image_name: 'chrisrahme/fyp-chatbot'
docker_registry_login: ${{ secrets.DOCKER_HUB_LOGIN }}
docker_registry_password: ${{ secrets.DOCKER_HUB_PASSWORD }}
docker_image_tag: ${{ github.sha }}
- name: "Upgrade a Rasa X deployment"
run: |
helm upgrade --install --reuse-values \
--set app.name=${{ steps.action_server.outputs.docker_image_name }} \
--set app.tag=${{ steps.action_server.outputs.docker_image_tag }} rasa rasa-x/rasa-x
When I update anything inside the actions folder and go to the “Actions” tab of my repository, the GitHub Action runs “Training and Testing” and then fails like so when in “Build Action Server Image”:
I’m new to GitHub actions, I don’t know if this error is my fault or not. In any case, is there a way to fix it, and how? I am currently using the docker build and docker push commands, but it would be way better to use a GitHub Action.
Wow you’re awesome, thanks a lot @tczekajlo. Turned out it was my Docker password indeed.
But I’ve run into another problem when the Action tries to run helm upgrade:
Run helm upgrade --install --reuse-values \
--set app.name=docker.io/***/fyp-chatbot \
--set app.tag=0d5b346bf67fd93c49b342717210e14a5f7800e6 rasa rasa-x/rasa-x
shell: /bin/bash -e {0}
env:
DOCKERFILE: /home/runner/work/_actions/RasaHQ/action-server-gha/main/default_files/Dockerfile
DOCKER_IMAGE_FULL_NAME: docker.io/***/fyp-chatbot:0d5b346bf67fd93c49b342717210e14a5f7800e6
RASA_SDK_VERSION: 2.3.1
Error: Kubernetes cluster unreachable: Get "http://localhost:8080/version?timeout=32s": dial tcp [::1]:8080: connect: connection refused
Error: Process completed with exit code 1.
When I enter that command directly on the server, it works fine:
$ helm upgrade --install --reuse-values --set app.name=docker.io/chrisrahme/fyp-chatbot --set app.tag=0d5b346bf67fd93c49b342717210e14a5f7800e6 rasa rasa-x/rasa-x
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /etc/rancher/k3s/k3s.yaml
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /etc/rancher/k3s/k3s.yaml
Release "rasa" has been upgraded. Happy Helming!
NAME: rasa
LAST DEPLOYED: Wed Feb 17 14:14:36 2021
NAMESPACE: rasa
STATUS: deployed
REVISION: 27
TEST SUITE: None
NOTES:
Thanks for installing Rasa X 0.35.1 !
Check out the Rasa X docs here for more help:
https://rasa.com/docs/rasa-x/
I have added export KUBECONFIG=/etc/rancher/k3s/k3s.yaml in ~\.bashrc. When I cat the file, I get this:
Your Kubernetes cluster has to be available via the Internet so that you can access it from a GH workflow. Additionally, you have to add a step in your workflow that will give you access to your cluster.
It looks like you use k3s on your local machine/server that’s is available only via localhost. It means that you won’t be able to reach your Kubernetes cluster from the GH workflow.
I am working on a server that is not yet available on the Internet yet. I don’t know how I haven’t thought of that… What are those steps I should add in the workflow by then?
For now, is it the same if I manually enter the helm upgrade command on the server after running the GitHub Action? Or do I keep using docker build and docker push?
I am working on a server that is not yet available on the Internet yet. I don’t know how I haven’t thought of that… What are those steps I should add in the workflow by then?
For now, is it the same if I manually enter the helm upgrade command on the server after running the GitHub Action? Or do I keep using docker build and docker push ?
The part responsible for building an image is ok, and you can leave it in your workflow, for now, it looks like you have to manually execute helm upgrade on your machine.
