This project helps you log & track your model backlog, from building through painting and being tabletop ready. If you have a pile of boxes or a collection of sprues, this project helps you manage that madness and watch your progress as you work through it.
TODO:
- Dark mode
- This is part of overall branding & design, looking for a designer
- Save units as one giant data batch, or save priorities better, or just improve this system SOMEHOW
- avro? super condensed info transfer
- tags for units
- filter on tags
- Custom columns
- Checkboxes instead of numbers
- projects & categories
- Tree view with N levels, N options at root
- page loader? this only seems to cover the full page, i want it on just the main project panel(s)
- account settings
- quick view
- customize auto save timer
- name (changeable?)
- does this matter if we having sharing links only? only matters if we end up with a "friends" system
- created & updated timestamps
- set your own start, end dates
- sharing links
- add friends
- set account private
- next 10 - a way to group the next 10 things you want to work on, across multiple projects
- stats
- by date, editable, with graphs
- export to CSV
- timelines w/ goals, show progress
- Fider for feedback
- Mobile layout
minor changes to make:
- Summary
far future:
- integrate math
- integrate games/crusade tracker
- games:
- track : army played, opponent army, opponent, date, win/loss, victory points (objectives/secondaries/turn), mission, game point value * freeform text box for army list?
- crusade:
- track: games (linked w/ above), roster, XP, abilities
- loose - this isn't rebuilding Crusade, this is free-text-enter that's easier & faster than excel.
- track: games (linked w/ above), roster, XP, abilities
- games:
GitHub Actions |
---|
Package | Stable | Prerelease |
---|---|---|
BoxToTabletop |
Make sure the following requirements are installed on your system:
- dotnet SDK 3.0 or higher
- Mono if you're on Linux or macOS.
or
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
DISABLE_COVERAGE
Will disable running code coverage metrics. AltCover can have severe performance degradation so it's worth disabling when looking to do a quicker feedback loop.DISABLE_COVERAGE=1 ./build.sh
> build.cmd <optional buildtarget> // on windows
$ ./build.sh <optional buildtarget>// on unix
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.GenerateCoverageReport
- Code coverage is run duringDotnetTest
and this generates a report via ReportGenerator.WatchApp
- Runs dotnet watch on the application. Useful for rapid feedback loops.WatchTests
- Runs dotnet watch with the test projects. Useful for rapid feedback loops.GenerateAssemblyInfo
- Generates AssemblyInfo for libraries.CreatePackages
- Runs the packaging task from dotnet-packaging. This creates applications forwin-x64
,osx-x64
andlinux-x64
- Runtime Identifiers.- Bundles the
win-x64
application in a .zip file. - Bundles the
osx-x64
application in a .tar.gz file. - Bundles the
linux-x64
application in a .tar.gz file.
- Bundles the
GitRelease
- Creates a commit message with the Release Notes and a git tag via the version in theRelease Notes
.GitHubRelease
- Publishes a GitHub Release with the Release Notes and any NuGet packages.FormatCode
- Runs Fantomas on the solution file.Release
- Task that runs all release type tasks such asGitRelease
andGitHubRelease
. Make sure to read Releasing to setup your environment correctly for releases.
Note that the Client command needs to be run in the directory with the package.json
file, so you still need to CD to that directory
./src/BoxToTabletop.Client/create-docker-image.sh
./src/BoxToTabletop/create-docker-image.sh
These instructions are for Digital Ocean, consult your cloud provider if hosting this project yourself somewhere else.
doctl registry login
docker tag registry.digitalocean.com/<my-registry>/<btt-client/btt-server>:<version>
docker tag registry.digitalocean.com/<my-registry>/<btt-client/btt-server>:latest
docker push registry.digitalocean.com/<my-registry>/<btt-client/btt-server>:<version>
docker push registry.digitalocean.com/<my-registry>/<btt-client/btt-server>:latest
Or just run ./tagAndPush.sh <image tag> <version>
in the server/client folders.
Deploy changes via the files in k8s
with kubectl apply -f <filename>
.
Find your running services with kubectl get pods
.
If you're on Digital Ocean with a Load Balancer, find your ports under Services
-> ingress-nginx-controller
(note that the ports are harder to find on the resource page itself, just check the internal endpoints on the table).
Note that TLS termination was done at the laod balancer in Digital Ocean so none of these were needed after all.
- Cert-manager for Kubernetes
- Installed via
kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.3.1/cert-manager.yaml
. This is a massive file & it's impossible to verify everything in it. - Also install the
cert-manager
kubectl plugin here. The config seems to merely create custom resource definitions, and not start anything, despite what the documentation says.
- Installed via
- Let's Encrypt On K8s - this seems out of date
git add .
git commit -m "Scaffold"
git remote add origin https://github.com/user/MyCoolNewApp.git
git push -u origin master
-
- You can then set the
GITHUB_TOKEN
to upload release notes and artifacts to github - Otherwise it will fallback to username/password
- You can then set the
-
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/MyCoolNewApp.git/compare/v0.1.0...HEAD
[0.1.0]: https://github.com/user/MyCoolNewApp.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 - push a git tag
- create a GitHub release for that git tag
- update
macOS/Linux Parameter:
./build.sh Release 0.2.0
macOS/Linux Environment Variable:
RELEASE_VERSION=0.2.0 ./build.sh Release