Add github workflow for release creation

.github/workflows/create-release.yml

@@ -0,0 +1,99 @@
+name: Create Release
+
+on:
+  push:
+    tags:
+      - 'build#*.*.*'
+
+env:
+  PREFIX_REGEX: 'build#(.*)'
+  IS_PRERELEASE: ${{ !startsWith(github.ref, 'refs/tags/build#') || contains(github.ref, '-') }}
+
+jobs:
+  create-release:
+    runs-on: ubuntu-latest
+    permissions:
+      # Give the default GITHUB_TOKEN write permission to commit and push the
+      # added or changed files to the repository.
+      contents: write
+
+    steps:
+      - name: Check out source code
+        uses: actions/checkout@v4
+
+      - name: Set up node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          cache: 'npm'
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Get current tag
+        id: get-tag
+        uses: devops-actions/[email protected]
+        with:
+          strip_v: false
+
+      - name: Get the new version
+        # Remove the prefix
+        id: get-version
+        run: |
+          rctag=${{ steps.get-tag.outputs.tag }}
+          re='${{ env.PREFIX_REGEX }}'
+          if [[ $rctag =~ $re ]]; then
+            echo "::debug::Tag matches regex pattern"
+            rctag=${BASH_REMATCH[1]}
+          else
+            echo "::debug::Tag DOES NOT match regex pattern"
+          fi
+          echo "version=$rctag" >> "$GITHUB_OUTPUT"
+
+      - name: Update package version to ${{ steps.get-version.outputs.version }}
+        uses: BellCubeDev/update-package-version-by-release-tag@v2
+        with:
+          version: ${{ steps.get-version.outputs.version }}
+
+      - name: Update library package version to ${{ steps.get-version.outputs.version }}
+        uses: BellCubeDev/update-package-version-by-release-tag@v2
+        with:
+          version: ${{ steps.get-version.outputs.version }}
+          package-json-path: './projects/log4ngx/package.json'
+
+      - name: Commit updated package
+        uses: stefanzweifel/git-auto-commit-action@v5
+        with:
+          commit_message: NPM package version updated to ${{ steps.get-version.outputs.version }}
+          branch: main
+          commit_user_name: ${{ github.actor }}
+          commit_user_email: ${{ github.actor }}@users.noreply.github.com
+
+      - name: Update git tag on latest commit
+        # The deletes the original prefixed tag on the remote (origin) repo but
+        # obviously doesn't remove it from any local repos that created/pulled
+        # the tag beforehand.  That shouldn't be an issue though, as we're only
+        # tidying it up because it's redundant.
+        run: |
+          git tag -d ${{ steps.get-tag.outputs.tag }}
+          git push origin :refs/tags/${{ steps.get-tag.outputs.tag }}
+          git tag v${{ steps.get-version.outputs.version }}
+          git push origin --tags
+
+      - name: Create draft Github pre-release for ${{ steps.get-version.outputs.version }} (${{ env.IS_PRERELEASE }})
+        if: env.IS_PRERELEASE == 'true'
+        uses: softprops/action-gh-release@v2
+        with:
+          name: ${{ steps.get-version.outputs.version }}
+          tag_name: ${{ steps.get-version.outputs.version }}
+          prerelease: true
+          draft: true
+
+      - name: Create draft Github release for ${{ steps.get-version.outputs.version }} (!${{ env.IS_PRERELEASE }})
+        if: env.IS_PRERELEASE == 'false'
+        uses: softprops/action-gh-release@v2
+        with:
+          name: ${{ steps.get-version.outputs.version }}
+          tag_name: ${{ steps.get-version.outputs.version }}
+          prerelease: false
+          draft: true

BUILD.md

@@ -0,0 +1,32 @@
+# Building log4ngx
+
+## Creating a release
+
+Draft releases are created automatically via a Github workflow when a tag is pushed to the `main`
+branch in [SemVer](https://semver.org/) format, with the tag's semver value being used as the
+version number of the release.  Tags should consist of the major, minor and patch versions and must
+be prefixed with "build#", e.g.
+
+    build#1.0.0
+    build#2.13.6
+
+Such version numbers will, by default, create a 'standard' release.  Should you need to build a
+'pre-release', the version tag should be suffixed with a hyphen and the appropriate build
+descriptor, e.g.
+
+    build#0.10.3-alpha
+    build#2.3.0-beta12
+
+> The release **must** be published manually from within Github as it is created as a _draft_,
+allowing the release notes to be added, prior to publishing.
+
+In creating the release, the "build#" prefix will be removed from the tag and the value used as the
+version number. The workflow will update the `version` properties in the repo's _package.json_ files
+for both the top-level project and the library, and then these updated files will be committed back
+to the repo.  Because the original 'build#' tag is no longer on the commit that represents the
+release, that tag will be deleted and a new tag matching the version number added to the new commit
+to correctly identify it as the source of the release.
+
+> This does mean that the release author (and anyone pulling the `main` branch after the build tag
+has been added but before the release has been created) will end up with a redundant tag in their
+local repo.  This can safely be ignored/deleted.

README.md

@@ -2,27 +2,40 @@
 
 [![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/secondbounce/log4ngx/badge)](https://scorecard.dev/viewer/?uri=github.com/secondbounce/log4ngx)
 
-log4ngx is a Typescript logging framework for Angular projects, based on concepts used in Log4j, Log4net, etc.
+log4ngx is a Typescript logging framework for Angular projects, based on concepts used in Log4j,
+Log4net, etc.
 
 > **Current Status**  
-> The library is now complete enough to be used in production if the `ConsoleAppender` and `LocalStorageAppender` are sufficient
-for your needs.
-> Documentation is being completed in the repository's Github Pages and will be updated as progress is made - as soon as it is in a reasonably complete state, a proper link will be made available here.
+> The library is now complete enough to be used in production if the `ConsoleAppender` and
+`LocalStorageAppender` are sufficient for your needs. Documentation is being completed in the
+repository and will be updated as progress is made - as soon as it is in a reasonably complete
+state, a proper link will be made available here.
+>
+> Until then, the [demo project](tree/main/projects/demo/) contains examples of configuring and
+using the library.
 
 ## Concepts
 
 ### LogService
 
-The `LogService` is the factory with which you instantiate `Loggers` in each of the components, services, etc, in which you wish to log messages.  Behind the scenes, it also orchestrates the dispatch of messages from the `Loggers` to the appropriate `Appenders`.
+The `LogService` is the factory with which you instantiate `Loggers` in each of the components,
+services, etc, in which you wish to log messages.  Behind the scenes, it also orchestrates the
+dispatch of messages from the `Loggers` to the appropriate `Appenders`.
 
 ### LogServiceConfig
 
-The `LogService` is configured using an instance of the `LogServiceConfig`, typically created in your application's main module.  The configuration defines the parameters used with each `Appender` and how each `Appender` relates to the various `Loggers`.
+The `LogService` is configured using an instance of the `LogServiceConfig`, typically created in
+your application's main module.  The configuration defines the parameters used with each `Appender`
+and how each `Appender` relates to the various `Loggers`.
 
 ### Loggers
 
-`Loggers` provide access to the methods for logging messages at the required `Level`.  Each class - i.e. component, module or service - will usually define its own `Logger` which will identify that class within any messages logged via it.
+`Loggers` provide access to the methods for logging messages at the required `Level`.  Each class -
+i.e. component, module or service - will usually define its own `Logger` which will identify that
+class within any messages logged via it.
 
 ### Appenders
 
-`Appenders` are responsible for sending log entries to the underlying target or service.  Configuration will normally depend on the target/service, but all `Appenders` are configured with the layout format for messages logged to them.
+`Appenders` are responsible for sending log entries to the underlying target or service.
+Configuration will normally depend on the target/service, but all `Appenders` are configured with
+the layout format for messages logged to them.

package.json

@@ -1,6 +1,6 @@
 {
   "name": "log4ngx",
-  "version": "18.0.0",
+  "version": "0.0.0",
   "description": "A Typescript logging framework for Angular projects",
   "author": "David Geary <[email protected]>",
   "license": "MIT",

projects/log4ngx/package.json

@@ -1,6 +1,6 @@
 {
   "name": "log4ngx",
-  "version": "18.0.0",
+  "version": "0.0.0",
   "description": "A Typescript logging framework for Angular projects",
   "author": "David Geary <[email protected]>",
   "license": "MIT",
@@ -18,8 +18,8 @@
     "typescript"
   ],
   "peerDependencies": {
-    "@angular/common": ">=16.0.0",
-    "@angular/core": ">=16.0.0"
+    "@angular/common": ">=18.0.0",
+    "@angular/core": ">=18.0.0"
   },
   "dependencies": {
     "tslib": "^2.3.0"