Library with utility functions
GitHub Actions |
---|
Package | Stable | Prerelease |
---|---|---|
Informedica.Utils.Lib |
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 indotnet build -c Debug
GITHUB_TOKEN
will be used to upload release notes and Nuget packages to GitHub.- Be sure to set this before releasing
> build.cmd <optional buildtarget> // on windows
$ ./build.sh <optional buildtarget>// on unix
The bin of your library should look similar to:
$ tree src/MyCoolNewLib/bin/
src/MyCoolNewLib/bin/
└── Debug
└── net50
├── MyCoolNewLib.deps.json
├── MyCoolNewLib.dll
├── MyCoolNewLib.pdb
└── MyCoolNewLib.xml
-
paket config add-token "https://www.nuget.org" 4003d786-cc37-4004-bfdf-c4f3e8ef9b3a
- or set the environment variable
NUGET_TOKEN
to your key
- or set the environment variable
-
- You can then set the environment variable
GITHUB_TOKEN
to upload release notes and artifacts to github - Otherwise it will fallback to username/password
- You can then set the environment variable
-
Then update the
CHANGELOG.md
with an "Unreleased" section containing release notes for this version, in KeepAChangelog format.
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 theRELEASE_VERSION
environment variable, or else as a parameter after the target name. This will:- update
CHANGELOG.md
, moving changes from theUnreleased
section into a new0.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
- update
Use the following tags for pushing changes to git:
- release
- feat: new feature
- fix: fix a bug or problem
- docs: document
- refactor: refactoring
- perf: improve performance
- test: add test
- chore: do a chore (build, libs, etc..)