Skip to main content
Version: 3.3.x

Continuous Integration / Deployment

Honeycomb leverages Continuous Integration/Deployment (CI/CD) to build the code and installers for different operating systems and settings, both on demand and automatically as code is pushed to the repository. Honeycomb's CI/CD is managed by GitHub Actions. These workflows provide Honeycomb's foundation and can easily be modified or extended to meet more needs.

What are Github Actions​

GitHub Actions automate tasks within the development life cycle of your software. GitHub Actions consist of a series of commands that run after a specified event has occurred. For example, every time someone creates a pull request for a repository, you can automatically run a command to build and test your software. You can learn more about the events that trigger workflows in GitHub's documentation

GitHub Actions are written as YML files inside the .github/workflows/ folder of your repository.

Honeycomb's CI/CD Workflows​

Honeycomb includes workflows to build and create installers for Windows, Mac and Linux, as well as for deploying to Firebase. These workflows exist for two configurations of the tasks:

  • Home: The app does not expect event code triggers and photodiode spots.
  • Clinic: The app expects event code triggers and photodiode spots.
tip

Event code triggers and photodiode spots can only be used on local applications! They will not appear when Honeycomb is deployed on the web.

  • pull_request.yaml: Every time a Pull Request (PR) is created the software is built and tests are run for all platforms with home and clinic settings. This workflow does not upload desktop installers.

  • release.yml: Every time a release is created, edited, or published installers for the Honeycomb app are created and uploaded to the release. This also builds a PsiTurk version and deploys the app to GitHub pages.

  • workflow-package.yaml: Create installers for any/all platforms for the home and/or clinic setting on demand. The installers/executables are uploaded as artifacts and are available for download from the GitHub Actions tab. This also builds a PsiTurk version when linux or all operating systems are selected.

    note

    On-demand workflows are triggered manually from the GitHub Actions tab. Each GitHub organization/individual has a quota on storage in private repositories. Uploading artifacts counts against your quota. You may consider configuring your workflows to only upload what you need. You can learn more about GitHub's storage limits in their official documentation.

  • workflow-delete-artifacts.yaml: On-demand workflow for deleting artifacts form your GitHub repository. This can be useful when the package.yaml workflow is run multiple times and you want to delete the artifacts from previous runs.

Firebase​

  • firebase-hosting-merge.yaml: Deploys the web version of the application to Firebase when a PR is merged into the main branch.
  • firebase-hosting-pull-request.yaml: Creates a preview version of the application with Firebase when a PR is opened.
    danger

    While this workflow uses a preview link it does use the production database. Ensure you use a test study to not conflict with your participant data.

note

These workflows may be safely deleted if you are not planning to ever use Firebase.