Before diving in, please be sure you have familiarized yourself with the Basics, especially the Constructs. Below we outline the process of onboarding your managed repository. Once complete, SkyLounge will continue to open pull requests with updates to automation and issues should automation updates fail.
Enable issues
SkyLounge uses GitHub Issues to provide feedback on errors. Please be sure Issues are enabled on your managed repository before onboarding. You can do this in GitHub by going to Settings
> Features
on your repository and selecting Issues
.
Onboarding managed repositories
We strive to simplify the process of onboarding managed repositories. You can onboard managed repositories by adding labels to the repository when using blueprint profiles. Otherwise, you can onboard applications manually. The net result is the same.
1. Onboarding with blueprint profiles
If your platform team has set up blueprint profiles, they will provide guidance on the available labels (you may need to edit the labels on your repository). SkyLounge will generate a skylounge.yml
file in a pull request. You will need to edit this pull request to fill in repository-specific details.
2. Manual blueprint selection
Alternatively, you can choose the appropriate blueprint for your application through the dashboard available at https://dashboard.skylounge.io. The blueprints page provides documentation for the blueprints you can access.
From this page, you can view the documentation for the blueprint, and all included workflow templates. You can also view and download the skylounge.yml
for each blueprint. Once you have chosen the appropriate blueprint, download the associated skylounge.yml
file and save it at the root of your repository.
skylounge.yml configuration
Regardless of your onboarding method, you must edit the skylounge.yml
file for each managed repository. The skylounge.yml is a single configuration file at the repository’s root that directs SkyLounge. It specifies the blueprint to use, the configurable job and step definitions, and parameters/configurations specific to the application. Whether you onboard manually or via repository labels, you must edit this file.
Depending on the blueprint, you may need to configure job definitions, step definitions, and/or parameters. Below is a sample skylounge.yml
showing the possible configuration inputs.
blueprint-uri: example-org/public-skylounge-library/blueprints/example/blueprint.yml
workflows:
- workflow: dev-example
jobs:
- job: setup
uri: # Job URI for `setup`. Example: example-org/our-app/skylounge/jobs/setup.yml
params:
setup-param: # Value for parameter `setup-param` in step `setup`.
- job: main
steps:
- step: custom-step
uri: # Step URI for `custom-step`. Example: example-org/our-app/skylounge/steps/custom-step.yml
params:
main-param: # Value for parameter `main-param` in job `main`.
params:
global-param: # Value for global parameter `global-param`.
You should be able to follow the comments to complete the configuration.
Configuring jobs and steps definitions
Jobs and steps definitions are referenced by URI, pointing to a file in GitHub. Job and step definitions may reside in your managed repository (as in the case of integration tests), or in your organization’s skylounge-library
(in the case of platform team-managed automation).
When referencing a shared job or step definition in a library repository, pay special attention to any additional parameters. You may need to add configuration for these paramters in your skylounge.yml
. Should you forget, do not fret. SkyLounge will open an issue highlighting the missing values.