dashy/docs/release-workflow.md

Releases and Workflows

• Release Schedule
• Automated Workflows
• Git Strategy

Release Schedule

We're using Semantic Versioning, to indicate major, minor and patch versions. You can find the current version number in the readme, and check your apps version under the config menu. The version number is pulled from the package.json file.

Typically there is a new major release every 2 weeks, usually on Sunday, and you can view these under the Releases Page. Each release will create a new tag on GitHub, and each major release will also result in the creation of a new tag on DockerHub, so that you can fix your container to a certain version.

For a full breakdown of each change, you can view the Changelog. Each new feature or significant change needs to be submitted through a pull request, which makes it easy to review and track these changes, and roll back if needed.

---

Automated Workflows

Dashy makes heavy use of GitHub Actions to fully automate the checking, testing, building, deploying of the project, as well as administration tasks like management of issues, tags, releases and documentation. The following section outlines each workflow, along with a link the the action file, current status and short description. A lot of these automations were made possible using community actions contributed to GH marketplace by some amazing people.

Code Processing

Action	Description
Code Linter	After a pull request is created, all new code changes will be linted, and the CI will fail with a helpful message if the code has any formatting inconsistencies
Code Spell Check	After a PR submitted, all auto-fixable spelling errors will be detected, then Liss-Bot will create a separate PR to propose the fixes
Dependency Update Summary	After a PR is submitted, if any of the dependencies are modified, then Liss-Bot will add a comment, explaining which packages have been added, removed, updated or downgraded, as well as other helpful info
Get Size	Adds comment to PR if the size of the built + bundled application has changed compared to the previous version
Security Scan	Uses Snyk to scan the code and dependencies after a PR. Will add a comment and cause the build to fail if a new vulnerability or potential issue is present

Releases

Action	Description
Create Tag	Whenever the version indicated in package.json is updates, a new GitHub tag will be created for that point in time
Build App	After changes are merged into the master branch, the app will be build, with output pushed to the dev-demo branch
Cache Artifacts	After build, returned files will be cached for future actions for that commit
Docker Publish	After PR is merged, the multi-architecture Docker container will be built, and then published to GHCR

Issue Management

Action	Description
Close Incomplete Issues	Issues which do not match any of the issue templates will be closed, and a comment posted explaining why
Close Stale Issues	Issues which have not been updated for 6 weeks will have a comment posted to them. If the author does not reply within the next week, then the issue will be marked as stale and closed. The original author may still reopen the issue at any time
Close Potential Spam Issues	Auto-closes issues, and adds a comment if it was submitted by a user who hasn't yet interacted with the repo, is new to GitHub and has not starred the repository. The comment will advise them to check their issue is complete, and then allow them to reopen it
Issue Translator	Auto-translates any comments and issues that were written in any language other than English, and posts the translation as a comment below
Label Sponsors	Adds a special label to any issues or pull requests raised by users who are sponsoring the project via GitHub, so that they can get priority support
LGTM Comment	When a PR review contains the words LGTM (looks good to me), the Liss-Bot will reply with a random celebratory or thumbs up GIF, just as a bit of fun
Mind your Language	Replies to any comment (on issue or PR) that contains profanities, offensive or inappropriate language with a polite note reminding the user of the code of conduct
Release Notifier	Once a release has been published which fixes an issue, a comment will be added to the relevant issues informing the user who raised it that it was fixed in the current release
Update Issue after Merge	After a PR which fixes an issue is merged, Liss-Bot will add a comment to said issue based on the git commit message
Auto Add Comment Based on Tag	Will add comment with useful info to certain issues, based on the tag applied

PR Management

Action	Description
PR Commenter	Adds comment with helpful info to pull requests, based on which files have been changes
Issue from Todo Code	When a todo note is found in the code after a PR, then Liss-Bot will automatically raise an issue, so that the todo can be addressed/ implemented. The issue will be closed once the todo has been implemented or removed

Documentation & Reports

Action	Description
Generate Credits	Generates a report, including contributors, collaborators, sponsors, bots and helpful users. Will then insert a markdown table with thanks to these GitHub users and links to their profiles into the Credits page, as well as a summary of sponsors and top contributors into the main readme
Wiki Sync	Generates and publishes the repositories wiki page using the markdown files within the docs directory

---

Git Strategy

Git Flow

Like most Git repos, we are following the Github Flow standard.

1. Create a branch (or fork if you don'd have write acces)
2. Code some awesome stuff, then add and commit your changes
3. Create a Pull Request, complete the checklist and ensure the build succeeds
4. Follow up with any reviews on your code
5. Merge 🎉

Git Branch Naming

The format of your branch name should be something similar to: [TYPE]/[TICKET]_[TITLE] For example, FEATURE/420_Awesome-feature or FIX/690_login-server-error

Commit Emojis

Using a single emoji at the start of each commit message, to indicate the type task, makes the commit ledger easier to understand, plus it looks cool.

• 🎨 :art: - Improve structure / format of the code.
• ⚡️ :zap: - Improve performance.
• 🔥 :fire: - Remove code or files.
• 🐛 :bug: - Fix a bug.
• 🚑️ :ambulance: - Critical hotfix
• ✨ :sparkles: - Introduce new features.
• 📝 :memo: - Add or update documentation.
• 🚀 :rocket: - Deploy stuff.
• 💄 :lipstick: - Add or update the UI and style files.
• 🎉 :tada: - Begin a project.
• ✅ :white_check_mark: - Add, update, or pass tests.
• 🔒️ :lock: - Fix security issues.
• 🔖 :bookmark: - Make a Release or Version tag.
• 🚨 :rotating_light: - Fix compiler / linter warnings.
• 🚧 :construction: - Work in progress.
• ⬆️ :arrow_up: - Upgrade dependencies.
• 👷 :construction_worker: - Add or update CI build system.
• ♻️ :recycle: - Refactor code.
• 🩹 :adhesive_bandage: - Simple fix for a non-critical issue.
• 🔧 :wrench: - Add or update configuration files.
• 🍱 :bento: - Add or update assets.
• 🗃️ :card_file_box: - Perform database schema related changes.
• ✏️ :pencil2: - Fix typos.
• 🌐 :globe_with_meridians: - Internationalization and translations.

For a full list of options, see gitmoji.dev

PR Guidelines

Once you've made your changes, and pushed them to your fork or branch, you're ready to open a pull request!

For a pull request to be merged, it must:

• Must be backwards compatible
• The build, lint and tests (run by GH actions) must pass
• There must not be any merge conflicts

When you submit your PR, include the required info, by filling out the PR template. Including:

• A brief description of your changes
• The issue, ticket or discussion number (if applicable)
• For UI relate updates include a screenshot
• If any dependencies were added, explain why it was needed, state the cost associated, and confirm it does not introduce any security issues
• Finally, check the checkboxes, to confirm that the standards are met, and hit submit!