Repository-specific job and step definitions must reside in your managed repository in a skyloungecopy directory in the repository’s root so that SkyLounge can identify file changes. For example:
...
skylounge\
jobs\
integration-test.yml
...
steps\
custom-container.yml
...
...
copyCustom job definitions
A job definition is a yamlcopy file following the GitHub job specification, with two key differences. First, it must have exactly one top-level key: the name of the job defined as per the skylounge.yml. Additionally, the file may use SkyLounge parameters (defined below). A job definition may only define a single job.
The example below shows an excerpt from an integration-testcopy job, without any SkyLounge parameters.
---
integration-test: # The name of the `skylounge-job`
needs: load-balancer
name: Integration Test
runs-on: ubuntu-latest
steps:
- name: Checkout develop branch
uses: actions/checkout@v3
...
copyCustom step definitions
A step definition file is a yamlcopy file following the GitHub steps specification, with two extensions. First, it must have exactly one top-level key, the steps:copy key. Additionally, the file may use SkyLounge parameters (defined below). A step definition may contain one or more steps.
The example below shows an excerpt from a gradlewcopy build step, with a SkyLounge parameter specifying the java-versioncopy.
---
steps:
- name: Set up Java
uses: actions/setup-java@v3
with:
distribution: "liberica"
java-version: ((jvm_version))
cache: "gradle"
- name: Unit test
run: ./gradlew test
- name: Build Jar
run: ./gradlew assemble
...
copySkyLounge parameters in job and step definitions
SkyLounge parameters extend the GitHub Actions syntax to enable configuration through a skylounge.yml file. Parameters are defined in custom job and step definitions using double parentheses notation: ((parameter))copy. Parameter names that start with an underscore (_) are optional and can be omitted. For example, ((_optional_parameter))copy can be omitted.