github-workflows

Reusable github workflows for FAIRDataTeam repositories.

General info

For more info about reusing workflows, see sharing automations documentation, specifically:

• avoiding-duplication
• reusing-workflows
• sharing-actions-and-workflows-with-your-organization

Dependent repos

The following FAIRDataTeam repositories depend on the reusable workflows from this repo:

• FAIRDataPoint
• FAIRDataPoint-client
• rdf-resource-resolver
• spring-rdf-migration
• spring-security-acl-mongodb

Examples

maven-publish

An example of a publication workflow that is triggered when a release is created, and re-uses two workflows:

name: Maven publish
on:
  release:
    types: [created]
jobs:
  test:
    uses: FAIRDataTeam/github-workflows/.github/workflows/maven-verify.yml@v2
  publish:
    needs: test
    uses: FAIRDataTeam/github-workflows/.github/workflows/maven-publish.yml@v2
    secrets: inherit

It is also possible to specify additional options for the maven-verify workflow, for example:

jobs:
  test:
    uses: FAIRDataTeam/github-workflows/.github/workflows/maven-verify.yml@v2
    with:
      mvn_options:  -Dgpg.skip tidy:check com.github.spotbugs:spotbugs-maven-plugin:check

maven-verify with database

The maven-verify workflow also supports optional database setup. For example:

jobs:
  test:
    uses: FAIRDataTeam/github-workflows/.github/workflows/maven-verify.yml@v2
    with:
      # the double quotes are required for windows runners
      mvn-options: '-D"spring.profiles.active"=testing'
      # db settings must match those defined in the spring profile
      db-type: postgresql
      db-name: fdp_test
      db-username: fdp
      db-password: fdp
      db-port: 54321

docker-publish

For pull requests, nothing is uploaded, but a test build is created.

The following variables and secrets must be defined in the calling repo (conforming to existing names from the FDP repos):

• vars.DOCKER_IMAGE_NAME
• vars.DOCKER_HUB_USERNAME
• secrets.DOCKER_HUB_PASSWORD

Secrets must be inherited from the caller.

The workflow could be triggered on push and pull_request (see [1]). For example:

name: publish to docker hub on push
on:
  push:
    branches:
      - develop
  pull_request:

jobs:
  publish:
    uses: FAIRDataTeam/github-workflows/.github/workflows/docker-publish.yml@v2
    secrets: inherit
    with:
      push: ${{ github.event_name != 'pull_request' }}

Alternatively, we could push on release creation only, for example:

name: publish to docker hub on release
on:
  release:
    types: [created]

jobs:
  publish:
    uses: FAIRDataTeam/github-workflows/.github/workflows/docker-publish.yml@v2
    secrets: inherit
    with:
      push: ${{ github.event_name == 'release' && github.event.action == 'created' }}

Releases

Releases follow semantic versioning. To get the latest stable release you can refer to the major version only, e.g. v2 instead of v2.3.4. Also see action versioning.

Note

Contributors, please read the contribution guidelines for instructions w.r.t. releases.