Skip to content

Finite state machine implementation in F#

License

Notifications You must be signed in to change notification settings

mchaloupka/Slp.Fsm

Repository files navigation

Slp.Fsm

Finite State Machine implementation.

The documentation is available at: https://mchaloupka.github.io/Slp.Fsm/


Builds

Build status

Build History

NuGet

Package Stable Prerelease
Slp.Fsm NuGet Badge NuGet Badge

Developing

Make sure the following requirements are installed on your system:

or


Environment Variables

  • CONFIGURATION will set the configuration of the dotnet commands. If not set, it will default to Release.
    • CONFIGURATION=Debug ./build.sh will result in -c additions to commands such as in dotnet build -c Debug
  • GITHUB_TOKEN will be used to upload release notes and Nuget packages to GitHub.
    • Be sure to set this before releasing

Building

> build.cmd <optional buildtarget>      # on windows
$ ./build.sh  <optional buildtarget>    # on unix

Build Targets

  • Clean - Cleans artifact and temp directories.
  • DotnetRestore - Runs dotnet restore on the solution file.
  • DotnetBuild - Runs dotnet build on the solution file.
  • DotnetTest - Runs dotnet test on the solution file.
  • WatchTests - Runs dotnet watch with the test projects. Useful for rapid feedback loops.
  • GenerateAssemblyInfo - Generates AssemblyInfo for libraries.
  • DotnetPack - Runs dotnet pack.
  • PublishToNuGet - Publishes the NuGet packages generated in DotnetPack to NuGet via paket push.
  • GitRelease - Creates a commit message with the Release Notes and a git tag via the version in the Release Notes.
  • GitHubRelease - Publishes a GitHub Release with the Release Notes and any NuGet packages.
  • FormatCode - Runs Fantomas on the solution file.
  • BuildDocs - Generates Documentation from docsSrc and the XML Documentation Comments from your libraries in src.
  • WatchDocs - Generates documentation and starts a webserver locally. It will rebuild and hot reload if it detects any changes made to docsSrc files, libraries in src, or the docsTool itself.
  • ReleaseDocs - Will stage, commit, and push docs generated in the BuildDocs target.
  • Release - Task that runs all release type tasks such as PublishToNuGet, GitRelease, ReleaseDocs, and GitHubRelease. Make sure to read Releasing to setup your environment correctly for releases.

Releasing

Create a cmd file build.release.cmd with the following content to create the release:

@echo off

set NUGET_TOKEN=<<nuget token>>
set GITHUB_TOKEN=<<github token>>

build.cmd %*

NOTE: Its highly recommend to add a link to the Pull Request next to the release note that it affects. The reason for this is when the RELEASE target is run, it will add these new notes into the body of git commit. GitHub will notice the links and will update the Pull Request with what commit referenced it saying "added a commit that referenced this pull request". Since the build script automates the commit message, it will say "Bump Version to x.y.z". The benefit of this is when users goto a Pull Request, it will be clear when and which version those code changes released. Also when reading the CHANGELOG, if someone is curious about how or why those changes were made, they can easily discover the work and discussions.

Here's an example of adding an "Unreleased" section to a CHANGELOG.md with a 0.1.0 section already released.

## [Unreleased]

### Added
- Does cool stuff!

### Fixed
- Fixes that silly oversight

## [0.1.0] - 2017-03-17
First release

### Added
- This release already has lots of features

[Unreleased]: https://github.com/user/MyCoolNewLib.git/compare/v0.1.0...HEAD
[0.1.0]: https://github.com/user/MyCoolNewLib.git/releases/tag/v0.1.0
  • You can then use the Release target, specifying the version number either in the RELEASE_VERSION environment variable, or else as a parameter after the target name. This will:
    • update CHANGELOG.md, moving changes from the Unreleased section into a new 0.2.0 section
      • if there were any prerelease versions of 0.2.0 in the changelog, it will also collect their changes into the final 0.2.0 entry
    • make a commit bumping the version: Bump version to 0.2.0 and adds the new changelog section to the commit's body
    • publish the package to NuGet
    • push a git tag
    • create a GitHub release for that git tag
build.release.cmd Release 0.2.0