UCloud logo UCloud logo UCloud
v2026.3.0
  1. UCloud/Core
  2. 1. Introduction
  3. 2. Projects
  4. 3. Accounting
  5. 4. Orchestration
  6. 5. Frontend
  7. UCloud/IM for Slurm-based HPC
  8. 6. Installation
  9. 7. Architecture and Networking
  10. 8. User and Project Management
  11. 9. Filesystem Integration
    1. 9.1. Inter-provider file transfers
  12. 10. Slurm Integration
    1. 10.1. Application Management
    2. 10.2. Built-in Applications
  13. 11. Reference
    1. 11.1. Configuration
    2. 11.2. CLI
  14. 12. Appendix
    1. 12.1. Built-in Application Index
  15. UCloud/IM for Kubernetes
  16. 13. Installation
  17. 14. Architecture and Networking
  18. 15. Filesystem Integration
  19. 16. Compute Jobs
    1. 16.1. Public Links
    2. 16.2. Public IPs
    3. 16.3. License Servers
    4. 16.4. SSH Servers
    5. 16.5. Job Audit Log
    6. 16.6. Virtual machines
  20. 17. Integrated applications
    1. 17.1. Syncthing
    2. 17.2. Integrated terminal
  21. 18. UCX applications
    1. 18.1. Hello world
    2. 18.2. Data binding
    3. 18.3. UI events
    4. 18.4. Component reference
    5. 18.5. API reference
  22. 19. Reference
    1. 19.1. Configuration
    2. 19.2. CLI
  23. Branding for UCloud
  24. 20. Branding and identity for UCloud
  25. H: Procedures
  26. 21. H: Procedures
  27. 22. H: Introduction
  28. 23. H: Auditing
  29. 24. H: Auditing scenario
  30. 25. H: GitHub actions
  31. 26. H: Deployment
  32. 27. H: 3rd party dependencies (risk assesment)
  1. Links
  2. Source Code
  3. Releases

GitHub Actions

We use GitHub actions for all of our automatic testing and continuous integration needs.

The workflow automatically triggers a new test run when one of the following things occur:

  1. The master branch receives a new commit

We implement this pipeline using a GitHub actions workflow. This file exists in the base folder of the UCloud project. This pipeline creates a UCloud cluster and runs tests against it. We create the cluster using the ./launcher script. This creates a functional cluster using all the real software. For example, this includes compute orchestrators such as Kubernetes and Slurm when relevant. This ensures that the testing environment is as realistic as possible.

A notification is automatically sent to GitHub about the test. We use the results of these tests to determine if we should deploy a specific build. According to our deployment procedures, it is not a requirement that tests pass. In the case of a build failure, then the development team is notified via Slack.

Previous H: Auditing scenario
Next H: Deployment