UCloud logo UCloud logo UCloud
v2026.3.0
  1. UCloud/Core
  2. 1. Introduction
  3. 2. Projects
  4. 3. Accounting
  5. 4. Orchestration
  6. UCloud/IM for Slurm-based HPC
  7. 5. Installation
  8. 6. Architecture and Networking
  9. 7. User and Project Management
  10. 8. Filesystem Integration
    1. 8.1. Inter-provider file transfers
  11. 9. Slurm Integration
    1. 9.1. Application Management
    2. 9.2. Built-in Applications
  12. 10. Reference
    1. 10.1. Configuration
    2. 10.2. CLI
  13. 11. Appendix
    1. 11.1. Built-in Application Index
  14. UCloud/IM for Kubernetes
  15. 12. Installation
  16. 13. Architecture and Networking
  17. 14. Filesystem Integration
  18. 15. Compute Jobs
    1. 15.1. Public Links
    2. 15.2. Public IPs
    3. 15.3. License Servers
    4. 15.4. SSH Servers
    5. 15.5. Job Audit Log
    6. 15.6. Virtual machines
  19. 16. Integrated applications
    1. 16.1. Syncthing
    2. 16.2. Integrated terminal
  20. 17. UCX applications
    1. 17.1. Hello world
    2. 17.2. Data binding
    3. 17.3. UI events
    4. 17.4. Component reference
    5. 17.5. API reference
  21. 18. Reference
    1. 18.1. Configuration
    2. 18.2. CLI
  22. Frontend development
  23. 19. Frontend description and development guidelines
  24. Branding for UCloud
  25. 20. Branding and identity for UCloud
  26. H: Procedures
  27. 21. H: Procedures
  28. 22. H: Introduction
  29. 23. H: Auditing
  30. 24. H: Auditing scenario
  31. 25. H: GitHub actions
  32. 26. H: Deployment
  33. 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