build: Automate release process #51
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Sep 18, 2024
Open
MikeRatcliffe
force-pushed
the
automate-release-process
branch
from
3cd7b10 to
9c4a27a
Compare
This commit fixes a missing code issue in the `patchNow` function of the App Tools modal. The issue was that the code was referencing a variable called `package` which wasn't actually being passed in the argument object. This commit updates the code to use the correct variable name `pkg`, which is now being passed in the argument object. This ensures that the App Tools modal functions correctly and can access the correct information about the application being managed.
This commit addresses an issue with sorting functionality in the "browse" and "remote" views within the application. The previous implementation of the `sortBy` function contained a nested function, which completely broke the sort functionality. This change also simplifies the `sortBy` function by making the sorting logic more straightforward and easier to understand. This improved clarity and maintainability will benefit developers working on the codebase.
Fixes VRPirates#34 Cleanly closes `adb` and `rclone` connections when the application exits, ensuring resources are freed and preventing potential issues. This addresses a previous oversight where these connections weren't properly closed, potentially leading to resource leaks and unexpected behavior. Even though we free up the adb connection we don't close the server because other programs may be using the connection. The changes introduce a `destroy()` function in `tools.js` that handles the cleanup. This function is called when the application receives the "will-quit" event, ensuring that resources are freed before the application terminates. This change enhances the application's reliability and stability by preventing resource leaks and ensuring a clean exit.
This commit addresses an issue where the keyboard shortcut (Ctrl+F or
Cmd+F) for opening the search dialog in the app was only functional
after the search dialog was already open. This change makes the keyboard
shortcut work regardless of the search dialog's current state.
The main change involves renaming the `openSearch()` function to
`toggleSearch()`, which now handles both opening and closing the search
dialog based on its current visibility. The logic for handling the
keyboard shortcut has been moved to the
`document.addEventListener("keydown", ...)` block, allowing for a more
robust and platform-independent solution.
Additionally, the `FindDialog` class has been modified to handle
toggling the search dialog's visibility dynamically, with a new
`display` parameter for the `toggle()` function. This provides more
control over the dialog's state and simplifies its usage.
This improvement provides a more intuitive and user-friendly experience
by ensuring that the search shortcut is always functional, regardless of
the current state of the search dialog.
These changes remove the `node-fetch` library from the project as it has been part of node for a number of years now, so the require is no longer needed.
These changes upgrade the project's styling framework from Bootstrap v4 to Bootstrap v5.3.3. This upgrade also impacts the project's layout by: - Removing the Bootswatch `bootstrap-slate.min.css` file as the theme is now handled by the official Bootswatch node module. - Updating the `main.css` file to accommodate the new Bootstrap classes and make necessary adjustments for elements like badges and form check inputs. - Modifying the `browse_include.twig`, `device_info.twig`, `index.twig`, and `modals/app_start.twig` files to use the new Bootstrap v5 classes and styling. Notably, this involves replacing deprecated classes like "pull-left" and "pull-right" with "float-start" and "float-end" respectively, along with other changes to button styling and form element types. The `views/css/bootstrap.min.css` file is removed because the new Bootstrap CSS is now included through the official `bootstrap` node module. The `views/js/bootstrap.min.js` file is also removed as the Bootstrap v5 require includes its own JavaScript files for its features, no longer requiring a separate Bootstrap JavaScript file. These changes aim to improve the project's styling, responsiveness, and user experience by utilizing the latest version of the popular Bootstrap framework. It also removes redundancy in the project's CSS and JavaScript files, contributing to a more streamlined codebase.
This commit introduces `lint-staged` to automate code formatting before
committing changes.
Previously, the `.husky/pre-commit` hook relied on
`npm run prettier:check`, which only performed a check for code style
violations but did not automatically fix them. This meant that
developers had to manually run `prettier` to format their code before
committing.
Most notably, using Husky to achieve this automatically formats only the
files that are to be committed, saving developers bot time and sanity.
The changes implement the following:
- **Update `.husky/pre-commit`:** The hook is now configured to run
`npm run pre-commit` which executes `lint-staged` to automatically
format code changes.
- **Add `pre-commit` script to `package.json`:** This script runs
`lint-staged` with the `--concurrent false` flag, ensuring that
formatting happens sequentially for improved compatibility with eslint
and reliability.
- **Modify `lint-staged` configuration in `package.json`:** The
configuration now targets specific file types
(`*.{css,html,js,json,md,twig,yml}`) for formatting. This clarifies the
scope of automatic formatting.
This change simplifies the development workflow by automating the code
formatting process, ensuring all commits adhere to the project's style
guidelines without manual intervention. This improves code consistency
and reduces the possibility of style-related issues in the codebase.
These changes introduce ESLint configuration to the project, establishing standardized code quality and style guidelines. The `eslint.config.mjs` file defines rules for JavaScript, HTML, and Twig files, ensuring code consistency and maintainability. Here's a breakdown of the key aspects: - **ESLint Integration:** The primary change is the introduction of ESLint rules. ESLint helps enforce consistent coding styles and identifies potential errors. - **Rule Configuration:** The `eslint.config.mjs` file specifies various ESLint rules for JavaScript, HTML, and Twig files, such as brace style, indentation, and semicolon usage. - **Global Declarations:** The ESLint configuration explicitly defines global variables, clarifying their usage and preventing unintended conflicts. - **Code Style Enforcement:** This setup enforces consistent code style across the project, making code easier to read and understand. - **Error Detection:** ESLint helps identify potential code issues early on, reducing the chances of runtime errors and improving code quality. - All current issues have been identified and fixed inside the codebase. Additionally, the changes to `main.js` illustrate the application of ESLint rules to existing code. The `no-unused-vars` rule is enabled, helping ensure that all variables are used within their scope. This change helps maintain code clarity and reduce clutter. Overall, these changes represent a significant step towards establishing a robust code quality and style framework for the project.
These changes introduce StylelintNow to the project, a tool for enforcing consistent CSS styles. Here's a breakdown: - **`.stylelintignore`:** This new file tells Stylelint to ignore certain files during checks, specifically `*.min.css`. This is useful for excluding minified CSS files, as they are often generated and shouldn't be directly edited. - **`.stylelintrc.json`:** This file contains Stylelint's configuration. It sets up the project to use `stylelint-config-standard`, a set of common Stylelint rules, ensuring a consistent code style across the project. - **`package-lock.json`:** This file records the exact versions of all dependencies, including Stylelint and its configuration. This ensures that the project's dependencies are reproducible and maintainable. - As usual, a number of CSS issues were identified and fixed within the codebase. Overall, these changes aim to improve code quality and maintainability by introducing automated CSS style checks. It ensures that the CSS code adheres to predefined standards and avoids inconsistent formatting. This will help reduce errors and improve the readability of the CSS codebase.
MikeRatcliffe
force-pushed
the
automate-release-process
branch
from
9c4a27a to
77eeef9
Compare
This commit introduces commitlint, a tool to enforce conventional commit messages. This is crucial for the automated release process (issue VRPirates#32) to work correctly, as it relies on conventional commit messages to generate the changelog. The commit includes the following changes: - Adds `commitlint.config.js` file that defines commitlint's rules for conventional commits. This config file ensures commits adhere to the Conventional Commits specification, allowing for automated changelog generation. - Adds a `.husky/commit-msg` hook which ensures that commitlint is run before each commit. - Adds `@commitlint/cli` and `@commitlint/config-conventional` packages to `package-lock.json` to enable commitlint functionality. - Updates `package.json` to add a "commitlint" script, allowing developers to run commitlint directly. By enforcing conventional commits, this commit improves the project's workflow, making releases more reliable and automated. It ensures the changelog is accurate and consistent, making it easier for developers and users to understand the project's history and changes.
These changes introduce Markdown linting to enforce consistent formatting and style in the project's Markdown files. The `markdownlint` and `markdownlint-cli` packages were added to the project's dependencies, and a configuration file `.markdownlint.jsonc` was created to specify the desired Markdown linting rules. The `markdownlint` command was added to the `package.json` scripts to enable linting as part of the build process. The addition of Markdown linting helps to ensure that the project's documentation is consistently formatted, improving readability and maintainability.
This commit introduces a `.vscode/extensions.json` file to the project, which provides recommendations for Visual Studio Code extensions. The inclusion of this file aims to streamline the development environment setup for contributors by suggesting a set of useful extensions commonly employed within the project. The recommended extensions cover various aspects of development, including: * **Code intelligence:** `npm-intellisense` and `path-intellisense` for enhanced JavaScript/Node.js and path handling. * **Documentation:** `jsdoc-generator` for generating JSDoc documentation, `vscode-markdownlint` for linting Markdown files. * **Linting and formatting:** `vscode-eslint`, `prettier-vscode`, and `vscode-stylelint` for enforcing coding style and best practices. * **HTML/Twig support:** `auto-close-tag`, `auto-rename-tag`, and `twig-language-2` for better HTML and Twig template development. * **Markdown assistance:** `markdown-all-in-one` for enhanced Markdown editing experience. By including these recommended extensions, contributors can quickly set up their VS Code environment with relevant tools, leading to a more productive and consistent coding experience.
This commit introduces a new file, `CONTRIBUTING.md`, which provides comprehensive guidelines for contributing to the Sidenoder project. The document covers various aspects of the contribution process, including setting up the development environment, running the project locally, making changes, committing code, submitting pull requests, code style guidelines, and reporting issues. By adding this file, the authors aim to make it easier for new contributors to understand the project's workflow and standards, thereby encouraging and streamlining the contribution process. This will help ensure that contributions are made in a consistent and efficient manner, ultimately improving the overall quality and maintainability of the Sidenoder codebase.
This commit introduces a fully automated release process for the project
using GitHub Actions. It replaces the manual build and release
workflows with a single, streamlined workflow (`build.yml`).
This new workflow builds the application for Mac, Windows, and Linux,
generates release notes based on conventional commit messages, creates a
new release on GitHub, and uploads the built binaries as release assets.
- Build for multiple OSs:
- macOs (Universal `dmg` for both Intel & M1)
- Windows `exe`
- Linux:
- `AppImage`
- `deb`
- `rpm`
- Changelog is automatically generated when a version number tag is
added to a commit e.g. `v0.9.2`.
This streamlines the release process and ensures consistent releases
across all platforms.
Usage:
1. Update version number in `package.json`.
2. ```
git commit -m "Release v0.9.2"
git push origin v0.9.2
```
3. That's it... a release will be automatically generated along with
conventional commit messages and installation packages for each
platform.
MikeRatcliffe
force-pushed
the
automate-release-process
branch
from
77eeef9 to
af5ff86
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #33
This is one pull request in a stack... they are all based on top of each other, so the order is important.
The advantage of this approach is that you are guaranteed no conflicts and reviews should be shorter.
Review each patch and merge before you move on to the next, this way, nothing will break and the code will be easier to review.
Start from #38 and work your way up the stack until you reach #51 (bottom to top).
mainAdds GitHub Actions workflow for automated releases, including:
To ensure we pick up all changes we should probably add the conventional commits pre-commit hook
to ensure commit messages contain the required
fix,featetc.The release process should be automated to generate a changelog, build packages for each platform
and generate a Github release.
Here is an example of the output:
