-
Using
- Importing Services & APIs
- Comparison to alternatives
- OpenAPI Mocking and Testing
- Swagger Mocking and Testing
- AsyncAPI Mocking and Testing
- Postman usage for Microcks
- gRPC Mocking and Testing
- GraphQL Mocking and Testing
- SoapUI Mocking and Testing
- Http Archive usage for Microcks
- Using exposed mocks
- Getting direct API
- Testing with Microcks
- Advanced topics
- Organizing repository
- Templating mock responses
- Dispatcher & dispatching rules
- Microcks APIMetadata
- Monitoring & Observability
- Installing
- Automating
- Administrating
- Guides
Using Microcks from GitHub Actions
🗓️ Last updated on November 22, 2021 | 3 | Improve this pageMicrocks GitHub Actions
What is it?
Microcks provides 2 GitHub Actions for interacting with a Microcks instance from your GitHub workflows:
-
The Microcks Import GitHub Action is a GitHub Action you may use in your Workflow to import a bunch of API artifacts in a Microcks installs. If test succeeds (ie. API endpoint is compliant with API contract in Microcks) the workflow is pursuing, if not it fails,
-
The Microcks Test GitHub Action is a GitHub Action you may use in your Workflow to launch a Microcks test on a deployed API endpoint. If test succeeds (ie. API endpoint is compliant with API contract in Microcks) the workflow is pursuing, if not it fails.
Those 2 actions are basically a wrapper around the Microcks CLI and provides the same configuration capabilities. Especially, they’re sharing the same mandatory configuration parameters that are
microcksURL
for the Microcks API endpoint,keycloakClientId
for the Keycloak Realm Service Account ClientId,keycloakClientSecret
for the Keycloak Realm Service Account ClientSecret.
How to use them?
Obviously we can find this action with GitHub Actions Marketplace 😉
You may add one of the Action to your Workflow directly from the GitHub UI.
Import GitHub action
The import
action, based on the CLI command, has just one argument that specifies a comma separated list of file paths:
<specificationFile1[:primary],specificationFile2[:primary]>
: The file paths with an optional flag telling if it should be imported asprimary
or not. See Multi-artifacts support doc. Default istrue
so it is considered as primary.
Step 1 - Configure the GH action
Here’s an example below:
name: my-workflow
on: [push]
jobs:
my-job:
runs-on: ubuntu-latest
environment: Development
steps:
- uses: microcks/import-github-action@v1
with:
specificationFiles: 'samples/weather-forecast-openapi.yml:true,samples/weather-forecast-postman.json:false'
microcksURL: 'https://microcks.apps.acme.com/api/'
keycloakClientId: ${{ secrets.MICROCKS_SERVICE_ACCOUNT }}
keycloakClientSecret: ${{ secrets.MICROCKS_SERVICE_ACCOUNT_CREDENTIALS }}
Step 2 - Configure the Secrets
As you probably saw just above, we do think it’s a best practice to use GitHub Secrets (general or tied to Environment
like in the example) to hold the Keycloak credentials (client Id and Secret). See below the Secrets configuration we’ve used for the example:
Test GitHub action
The test
action, based on the CLI command, needs 3 arguments:
<apiName:apiVersion>
: Service to test reference. Exemple:'Beer Catalog API:0.9'
<testEndpoint>
: URL where is deployed implementation to test<runner>
: Test strategy (one of:HTTP
,SOAP
,SOAP_UI
,POSTMAN
,OPEN_API_SCHEMA
,ASYNC_API_SCHEMA
)
And some optional ones:
--waitFor
for the time to wait for test to finish (int + one of: milli, sec, min). Default is5sec
,--secretName='<Secret Name>'
is an optional flag specifying the name of a Secret to use for connecting endpoint,--operationsHeaders=<JSON>
allows to override some operations headers for the tests to launch.
Step 1 - Configure the GH action
Here’s an example below:
name: my-workflow
on: [push]
jobs:
my-job:
runs-on: ubuntu-latest
environment: Development
steps:
- uses: microcks/test-github-action@v1
with:
apiNameAndVersion: 'API Pastry - 2.0:2.0.0'
testEndpoint: 'http://my-api-pastry.apps.cluster.example.com'
runner: OPEN_API_SCHEMA
microcksURL: 'https://microcks.apps.acme.com/api/'
keycloakClientId: ${{ secrets.MICROCKS_SERVICE_ACCOUNT }}
keycloakClientSecret: ${{ secrets.MICROCKS_SERVICE_ACCOUNT_CREDENTIALS }}
waitFor: '10sec'
Step 2 - Configure the Secrets
As you probably saw just above, we do think it’s a best practice to use GitHub Secrets (general or tied to Environment
like in the example) to hold the Keycloak credentials (client Id and Secret). See below the Secrets configuration we’ve used for the example:
Still Didn’t Find Your Answer?
Join our community and get the help you need. Engage with other members, ask questions, and share knowledge to resolve your queries and expand your understanding.
Join the community