This action makes the protoc compiler available to Workflows.

To get the latest stable version of protoc just add this step:

- name: Install Protoc
  uses: arduino/setup-protoc@v1

If you want to pin a major or minor version you can use the .x wildcard:

- name: Install Protoc
  uses: arduino/setup-protoc@v1
  with:
    version: '3.x'

You can also require to include releases marked as pre-release in Github using the include-pre-releases flag (the dafault value for this flag is false)

- name: Install Protoc
  uses: arduino/setup-protoc@v1
  with:
    version: '3.x'
    include-pre-releases: true

To pin the exact version:

- name: Install Protoc
  uses: arduino/setup-protoc@v1
  with:
    version: '3.9.1'

The action queries the GitHub API to fetch releases data, to avoid rate limiting, pass the default token with the repo-token variable:

- name: Install Protoc
  uses: arduino/setup-protoc@v1
  with:
    repo-token: ${{ secrets.GITHUB_TOKEN }}

To work on the codebase you have to install all the dependencies:

# npm install

To run the tests:

# npm run test

Additional log events with the prefix ::debug:: can be enabled by setting the secret ACTIONS_STEP_DEBUG to true.

See step-debug-logs for reference.

We check in the node_modules to provide runtime dependencies to the system using the Action, so be careful not to git add all the development dependencies you might have under your local node_modules. To release a new version of the Action the workflow should be the following:

1. npm install to add all the dependencies, included development.
2. npm run test to see everything works as expected.
3. npm run build to build the Action under the ./lib folder.
4. rm -rf node_modules to remove all the dependencies.
5. npm install --production to add back only the runtime dependencies.
6. git add lib node_modules to check in the code that matters.
7. If the release will increment the major version, update the action refs in the examples in README.md (e.g., uses: arduino/setup-protoc@v1 -> uses: arduino/setup-protoc@v2).
8. open a PR and request a review.
9. After PR is merged, create a release, following the vX.X.X tag name convention.
10. After the release, rebase the release branch for that major version (e.g., v1 branch for the v1.x.x tags) on the tag. If no branch exists for the release's major version, create one.

If you think you found a vulnerability or other security-related bug in this project, please read our security policy and report the bug to our Security Team 🛡️ Thank you!

e-mail contact: [email protected]