Skip to content

opennetworkinglab/aether-onramp

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

368 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

GitHub Actions Workflows

This directory contains GitHub Actions workflows for the Aether OnRamp project.

Quickstart Workflow

The quickstart.yml workflow replicates the functionality of the Jenkins groovy workflow found at opennetworkinglab/aether-jenkins.

Workflow Stages

  1. Checkout repository: Clones the repo with all submodules
  2. Set up Python: Installs Python and creates a virtual environment with Ansible
  3. Install kubectl: Uses Azure's setup-kubectl action (default/latest version as specified in requirements)
  4. Install Helm: Uses Azure's setup-helm action (default/latest version as specified in requirements)
  5. Configure OnRamp: Sets up SSH keys, generates hosts.ini, configures vars/main.yml
  6. Install Aether: Installs Kubernetes, 5GC core, and gNBsim
  7. Run gNBsim: Executes the gNBsim test with retry logic (2 attempts)
  8. Validate Results: Checks that tests passed using the same validation pattern as Jenkins
  9. Retrieve Logs: Collects logs from all components
  10. Archive Artifacts: Uploads logs as workflow artifacts
  11. Cleanup: Uninstalls all components (always runs, even on failure)
  12. Notify on Failure: Logs failure information (can be extended with Slack notifications)

Triggering the Workflow

The workflow has the following triggers:

  1. Manual Dispatch: Go to Actions → Aether OnRamp Quickstart → Run workflow
  2. Push to main: Automatically runs on pushes to the main branch

Differences from Jenkins Workflow

The GitHub Actions workflow includes the following changes from the original Jenkins groovy script:

  1. Runtime Installation: kubectl, helm, and Python virtualenv are installed at runtime instead of relying on pre-installed tools
  2. Local Execution: Ansible runs with ansible_connection=local instead of SSH, since the workflow runs directly on the runner
  3. Self-Contained: All dependencies are installed fresh for each run
  4. Error Handling: Enhanced with conditional steps and proper cleanup

Troubleshooting

If the workflow fails:

  1. Check the workflow run logs in the Actions tab
  2. Download the archived logs artifacts for detailed component logs
  3. Ensure the runner has sufficient resources (disk space, memory)
  4. Check that network configuration is correct for your environment

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Contributors 8