goirsdk
Sample usage
Start the iRacing simulator and wait until the simulation is up and running.
cd sample
go run sample.go
The sample connects to the iRacing telemetry data and prints out the iRacing session time every second.
See variables for an overview of available telemetry data
Initial Setup
This section is intended to help developers and contributors get a working copy of
goirsdk
on their end
Clone this repository
git clone https://github.com/mpapenbr/goirsdk
cd goirsdk
Option: Do you own setup
Install golangci-lint
from the official website for your OS
Local Development
This section will guide you to setup a fully-functional local copy of goirsdk
on your end and teach you how to use it! Make sure you have installed
golangci-lint before following this section!
Note: This section relies on the usage of Makefile. If you
can't (or don't) use Makefile, you can follow along by running the internal commands
from goirsdk's
Makefile (most of which are
OS-independent)!
Installing dependencies
To install all dependencies associated with goirsdk
, run the
command
make install
Code formatters format your code to match pre-decided conventions. To run automated code
formatters, use the Makefile command
make codestyle
Using Code Linters
Linters are tools that analyze source code for possible errors. This includes typos,
code formatting, syntax errors, calls to deprecated functions, potential security
vulnerabilities, and more!
To run pre-configured linters, use the command
make lint
Additional Resources
Makefile help
Tap for a list of Makefile commands
Command |
Description |
Prerequisites |
help |
Generate help dialog listing all Makefile commands with description |
NA |
| install
| Fetch project dependencies | NA |
| codestyle
| Run code-formatters | golangci-lint |
| lint
| Check codestyle and run linters | golangci-lint |
Optionally, to see a list of all Makefile commands, and a short description of what they
do, you can simply run
make
Which is equivalent to;
make help
Both of which will list out all Makefile commands available, and a short description
of what they do!
Releases
You can check out a list of previous releases on the Github Releases
page.
Semantic versioning with Release Drafter
What is Semantic Versioning?
Semantic versioning is a versioning scheme aimed at making software management easier.
Following semantic versioning, version identifiers are divided into three parts;
<major>.<minor>.<patch>
MAJOR version when you make incompatible API changes [breaking changes]
MINOR version when you add functionality in a backwards compatible manner [more features]
PATCH version when you make backwards compatible bug fixes [bug fixes and stuff]
For a more detailed description, head over to semver.org
Release Drafter automatically updates the release version as pull
requests are merged.
Labels allowed;
major
: Affects the <major>
version number for semantic versioning
minor
, enhancement
, update
, feature
: Affects the <minor>
version number for semantic versioning
- all other labels affect the
<patch>
version number
Whenever a pull request with one of these labels is merged to the master
branch,
the corresponding version number will be bumped by one digit!
List of Labels
Pull requests once merged, will be classified into categories by
release-drafter based on pull request labels
This is managed by the release-drafter.yml
config file.
Label |
Title in Releases |
security |
๐ Security |
enhancement , feature , update |
๐ Updates |
bug , bugfix , fix |
๐ Bug Fixes |
documentation , docs |
๐ Documentation |
wip , in-progress , incomplete , partial , hotfix |
๐ง Work in Progress |
dependencies , dependency |
๐ฆ Dependencies |
refactoring , refactor , tests , testing |
๐งช Tests and Refactor |
build , ci , pipeline |
๐ค CI/CD and Pipelines |
The labels bug
, enhancement
, and documentation
are automatically created by Github
for repositories. Dependabot will implicitly create the
dependencies
label with the first pull request raised by it.
The remaining labels can be created as needed!
Credits