matous-volf/todo-baggins
matous-volf/todo-baggins
1
0
Fork 0
Code Issues 23 Pull Requests Actions Projects 1 Activity

ci: GitHub action for code linting #6

Merged
matous-volf merged 5 commits from ci/lint-check into main 2024-08-15 11:55:20 +00:00
Conversation 5 Commits 5 Files Changed 3 +58 -4
matous-volf commented 2024-08-15 10:42:49 +00:00 (Migrated from github.com)
Copy Link

Summary by CodeRabbit

  • New Features

    • Introduced a new continuous integration workflow for automatic code linting on pull request events.

  • Improvements

    • Enhanced clarity of GitHub Actions workflows by renaming steps for better readability, including "checkout code" and "conventional commits check."
    • Updated the pull request validation step name to "conventional pull requests check" for improved intuitiveness.
    • Added explicit permission management in workflows to improve security and control.
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Introduced a new continuous integration workflow for automatic code linting on pull request events. - **Improvements** - Enhanced clarity of GitHub Actions workflows by renaming steps for better readability, including "checkout code" and "conventional commits check." - Updated the pull request validation step name to "conventional pull requests check" for improved intuitiveness. - Added explicit permission management in workflows to improve security and control. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
coderabbitai[bot] commented 2024-08-15 10:42:56 +00:00 (Migrated from github.com)
Copy Link

Walkthrough

The recent changes improve the clarity and usability of GitHub Actions workflows by renaming steps to better reflect their purposes. Key updates include the introduction of a new linting workflow for automated code quality checks and explicit permission management across workflows. These modifications enhance maintainability and readability while preserving the existing functionality of the workflows.

Changes

Files Change Summary
.github/workflows/conventional-commits.yml, .github/workflows/conventional-pull-requests.yml Steps renamed for clarity: "checkout code," "conventional commits check," and "conventional pull requests check." Permissions added for improved security management.
.github/workflows/lint.yml New linting workflow introduced to automate code quality checks on pull request events.
Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.
<!-- This is an auto-generated comment: summarize by coderabbit.ai --> <!-- walkthrough_start --> ## Walkthrough The recent changes improve the clarity and usability of GitHub Actions workflows by renaming steps to better reflect their purposes. Key updates include the introduction of a new linting workflow for automated code quality checks and explicit permission management across workflows. These modifications enhance maintainability and readability while preserving the existing functionality of the workflows. ## Changes | Files | Change Summary | |-----------------------------------------------|---------------------------------------------------------------------------------------------------------| | `.github/workflows/conventional-commits.yml`, `.github/workflows/conventional-pull-requests.yml` | Steps renamed for clarity: "checkout code," "conventional commits check," and "conventional pull requests check." Permissions added for improved security management. | | `.github/workflows/lint.yml` | New linting workflow introduced to automate code quality checks on pull request events. | <!-- walkthrough_end --><!-- This is an auto-generated comment: raw summary by coderabbit.ai --> <!-- ```markdown .github/workflows/conventional-commits.yml: ## AI-generated summary of changes The changes in the provided diff primarily enhance the clarity and structure of the GitHub Actions workflow defined in the `.github/workflows/conventional-commits.yml` file. Key modifications include the introduction of a `permissions` block at the job level, which specifies the access rights for various components involved in the workflow. This addition establishes explicit permissions for `contents`, `pull-requests`, `packages`, and `statuses`, thereby improving security and control over the actions that the workflow can perform. Furthermore, the steps within the workflow have been renamed to provide clearer descriptions of their functions. The previously unnamed step for checking out the code is now labeled as "checkout code," while the step for executing the conventional commits check is renamed to "conventional commits check." These updates not only enhance the readability of the workflow but also aid in understanding the purpose of each step at a glance. Overall, these changes do not alter the underlying functionality of the workflow; rather, they improve its maintainability and usability by making the intentions behind each action more explicit. ## Alterations to the declarations of exported or public entities - `permissions` block added in `.github/workflows/conventional-commits.yml`. - Step declaration for `actions/checkout@v3` in `.github/workflows/conventional-commits.yml` changed from unnamed to `name: checkout code`. - Step declaration for `webiny/action-conventional-commits@v1.3.0` in `.github/workflows/conventional-commits.yml` changed from unnamed to `name: conventional commits check`. - `permissions` for the job `build` in `.github/workflows/conventional-commits.yml` now includes: - `contents: read` - `pull-requests: read` - `packages: read` - `statuses: write` --- .github/workflows/conventional-pull-requests.yml: ## AI-generated summary of changes The diff introduces several updates to the GitHub Actions workflow defined in the `.github/workflows/conventional-pull-requests.yml` file. Notably, a new job named `build` has been added, which replaces the previous job `validate-pr-title`. This job is configured to run on the `ubuntu-22.04` environment and is focused on validating conventional pull requests. The permissions for this job have been explicitly defined, granting read access to contents, pull requests, and packages, while allowing write access to statuses. This enhancement improves the clarity of permission management within the workflow. Additionally, the step previously named "PR Conventional Commit Validation" has been renamed to "conventional pull requests check," which enhances the semantic clarity of the workflow. Despite these changes, the core functionality remains intact, as the step continues to utilize the same action (`ytanikin/PRConventionalCommits@1.1.0`) with the same parameters for validating commit messages against specified task types. Overall, these modifications streamline the workflow and improve its readability without altering the fundamental operations. ## Alterations to the declarations of exported or public entities - `jobs.validate-pr-title` in `.github/workflows/conventional-pull-requests.yml` → `jobs.build` in `.github/workflows/conventional-pull-requests.yml` - `name: PR Conventional Commit Validation` in `.github/workflows/conventional-pull-requests.yml` → `name: conventional pull requests check` in `.github/workflows/conventional-pull-requests.yml` - `permissions: { }` added in `.github/workflows/conventional-pull-requests.yml` - `permissions:` section modified in `jobs.build` in `.github/workflows/conventional-pull-requests.yml` to include specific permissions. --- .github/workflows/lint.yml: ## AI-generated summary of changes The newly added GitHub Actions workflow file `.github/workflows/lint.yml` implements a continuous integration mechanism focused on code linting. This workflow is activated by several pull request events, including opening, synchronizing, reopening, and editing pull requests. It runs in an Ubuntu environment, ensuring support for a wide range of programming languages and coding standards. The workflow consists of a single job named "lint," tasked with executing the linting operations. It begins by checking out the code repository using the `actions/checkout` action, which is configured to fetch the entire git history. This is essential for the super-linter to effectively track changes across commits. The main component of the linting process is the `super-linter` action, a powerful tool capable of linting multiple languages and frameworks. The workflow is equipped with several environment variables that customize the linter's behavior. Key configurations include options to automatically fix formatting issues in various file types, such as CSS, HTML, JavaScript, JSON, Rust, TypeScript, and YAML. Additionally, the `GITHUB_TOKEN` is provided to facilitate the action's ability to report the status of the checks back to GitHub, ensuring that the outcomes of the linting process are visible in the pull request interface. In summary, this workflow significantly enhances the project's quality assurance by automating the linting process, thereby helping to uphold coding standards and minimize the risk of errors being introduced through pull requests. ## Alterations to the declarations of exported or public entities - `name: lint` in `.github/workflows/lint.yml` → `name: lint` in `.github/workflows/lint.yml` - `on: pull_request` in `.github/workflows/lint.yml` → `on: pull_request` in `.github/workflows/lint.yml` - `jobs: build` in `.github/workflows/lint.yml` → `jobs: build` in `.github/workflows/lint.yml` - `steps: checkout code` in `.github/workflows/lint.yml` → `steps: checkout code` in `.github/workflows/lint.yml` - `steps: Super-linter check` in `.github/workflows/lint.yml` → `steps: Super-linter check` in `.github/workflows/lint.yml` ``` --> <!-- end of auto-generated comment: raw summary by coderabbit.ai --><!-- This is an auto-generated comment: pr objectives by coderabbit.ai --> <!-- ## PR summary This pull request introduces a GitHub Action aimed at implementing code linting for the repository. The action will help automate the process of checking the code for stylistic and programming errors, ensuring that the codebase adheres to defined coding standards. By integrating this linting process into the continuous integration workflow, it enhances code quality and maintainability. The pull request was submitted by the user `matous-volf` and is identified as number 6 in the repository. No additional description or context has been provided in the pull request. ## Objectives summary Title: ci: GitHub action for code linting Number: 6 User: matous-volf --> <!-- end of auto-generated comment: pr objectives by coderabbit.ai --><!-- commit_ids_reviewed_start --> <!-- e130da77f48f8cd2fb47db85eae2bb37c3485019 --> <!-- 2d1f1aa05b8c8bf327cdb15ffacf296ff8eb2390 --> <!-- commit_ids_reviewed_end --><!-- tips_start --> --- <details> <summary>Tips</summary> ### Chat There are 3 ways to chat with [CodeRabbit](https://coderabbit.ai): - Review comments: Directly reply to a review comment made by CodeRabbit. Example: - `I pushed a fix in commit <commit_id>.` - `Generate unit testing code for this file.` - `Open a follow-up GitHub issue for this discussion.` - Files and specific lines of code (under the "Files changed" tab): Tag `@coderabbitai` in a new review comment at the desired location with your query. Examples: - `@coderabbitai generate unit testing code for this file.` - `@coderabbitai modularize this function.` - PR comments: Tag `@coderabbitai` in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples: - `@coderabbitai generate interesting stats about this repository and render them as a table.` - `@coderabbitai show all the console.log statements in this repository.` - `@coderabbitai read src/utils.ts and generate unit testing code.` - `@coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.` - `@coderabbitai help me debug CodeRabbit configuration file.` Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. ### CodeRabbit Commands (invoked as PR comments) - `@coderabbitai pause` to pause the reviews on a PR. - `@coderabbitai resume` to resume the paused reviews. - `@coderabbitai review` to trigger an incremental review. This is useful when automatic reviews are disabled for the repository. - `@coderabbitai full review` to do a full review from scratch and review all the files again. - `@coderabbitai summary` to regenerate the summary of the PR. - `@coderabbitai resolve` resolve all the CodeRabbit review comments. - `@coderabbitai configuration` to show the current CodeRabbit configuration for the repository. - `@coderabbitai help` to get help. Additionally, you can add `@coderabbitai ignore` anywhere in the PR description to prevent this PR from being reviewed. ### CodeRabbit Configuration File (`.coderabbit.yaml`) - You can programmatically configure CodeRabbit by adding a `.coderabbit.yaml` file to the root of your repository. - Please see the [configuration documentation](https://docs.coderabbit.ai/guides/configure-coderabbit) for more information. - If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: `# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json` ### Documentation and Community - Visit our [Documentation](https://coderabbit.ai/docs) for detailed information on how to use CodeRabbit. - Join our [Discord Community](https://discord.com/invite/GsXnASn26c) to get help, request features, and share feedback. - Follow us on [X/Twitter](https://twitter.com/coderabbitai) for updates and announcements. </details> <!-- tips_end -->
coderabbitai[bot] (Migrated from github.com) reviewed 2024-08-15 10:45:36 +00:00
coderabbitai[bot] (Migrated from github.com) left a comment
Copy Link

Actionable comments posted: 0

Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE

Commits

Files that changed from the base of the PR and between 82b6b3475f and e130da77f4.

Files selected for processing (3)
  • .github/workflows/conventional-commits.yml (1 hunks)
  • .github/workflows/conventional-pull-requests.yml (1 hunks)
  • .github/workflows/lint.yml (1 hunks)
Additional comments not posted (3)
.github/workflows/conventional-commits.yml (1)

12-15: Improved step naming for clarity.

The renaming of steps to "checkout code" and "conventional commits check" enhances the readability and maintainability of the workflow.

.github/workflows/conventional-pull-requests.yml (1)

11-11: Improved step naming for clarity.

Renaming the step to "conventional pull requests check" aligns with its purpose and enhances readability.

.github/workflows/lint.yml (1)

1-40: New linting workflow added.

The introduction of a linting workflow using super-linter enhances code quality automation. The configuration is comprehensive, covering multiple languages and formats.

Consider verifying the compatibility of super-linter@v6.9.0 with your codebase to ensure optimal functionality.

**Actionable comments posted: 0** <details> <summary>Review details</summary> **Configuration used: CodeRabbit UI** **Review profile: ASSERTIVE** <details> <summary>Commits</summary> Files that changed from the base of the PR and between 82b6b3475f5edad4c20e627cd5f3de780e73e9a6 and e130da77f48f8cd2fb47db85eae2bb37c3485019. </details> <details> <summary>Files selected for processing (3)</summary> * .github/workflows/conventional-commits.yml (1 hunks) * .github/workflows/conventional-pull-requests.yml (1 hunks) * .github/workflows/lint.yml (1 hunks) </details> <details> <summary>Additional comments not posted (3)</summary><blockquote> <details> <summary>.github/workflows/conventional-commits.yml (1)</summary><blockquote> `12-15`: **Improved step naming for clarity.** The renaming of steps to "checkout code" and "conventional commits check" enhances the readability and maintainability of the workflow. </blockquote></details> <details> <summary>.github/workflows/conventional-pull-requests.yml (1)</summary><blockquote> `11-11`: **Improved step naming for clarity.** Renaming the step to "conventional pull requests check" aligns with its purpose and enhances readability. </blockquote></details> <details> <summary>.github/workflows/lint.yml (1)</summary><blockquote> `1-40`: **New linting workflow added.** The introduction of a linting workflow using `super-linter` enhances code quality automation. The configuration is comprehensive, covering multiple languages and formats. Consider verifying the compatibility of `super-linter@v6.9.0` with your codebase to ensure optimal functionality. </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
coderabbitai[bot] (Migrated from github.com) reviewed 2024-08-15 10:45:39 +00:00
coderabbitai[bot] (Migrated from github.com) requested changes 2024-08-15 11:53:17 +00:00
coderabbitai[bot] (Migrated from github.com) left a comment
Copy Link

Actionable comments posted: 3

Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE

Commits

Files that changed from the base of the PR and between e130da77f4 and 2d1f1aa05b.

Files selected for processing (3)
  • .github/workflows/conventional-commits.yml (1 hunks)
  • .github/workflows/conventional-pull-requests.yml (1 hunks)
  • .github/workflows/lint.yml (1 hunks)
Additional comments not posted (7)
.github/workflows/conventional-commits.yml (2)

13-17: Approve the addition of explicit permissions.

Defining explicit permissions for the build job enhances security by restricting access to only necessary resources.

19-22: Approve the improved step naming.

Renaming the steps for clarity enhances the readability of the workflow.

.github/workflows/conventional-pull-requests.yml (2)

13-17: Approve the addition of explicit permissions.

Defining explicit permissions for the build job enhances security by restricting access to only necessary resources.

19-21: Approve the improved step naming.

Renaming the steps for clarity enhances the readability of the workflow.

.github/workflows/lint.yml (3)

13-17: Approve the addition of explicit permissions.

Defining explicit permissions for the build job enhances security by restricting access to only necessary resources.

19-23: Approve the checkout step configuration.

The checkout code step is correctly configured with fetch-depth: 0 to ensure the full git history is available for the super-linter.

24-37: Approve the comprehensive super-linter configuration.

The super-linter is configured to validate multiple code types and automatically fix issues where possible, which helps maintain code quality.

**Actionable comments posted: 3** <details> <summary>Review details</summary> **Configuration used: CodeRabbit UI** **Review profile: ASSERTIVE** <details> <summary>Commits</summary> Files that changed from the base of the PR and between e130da77f48f8cd2fb47db85eae2bb37c3485019 and 2d1f1aa05b8c8bf327cdb15ffacf296ff8eb2390. </details> <details> <summary>Files selected for processing (3)</summary> * .github/workflows/conventional-commits.yml (1 hunks) * .github/workflows/conventional-pull-requests.yml (1 hunks) * .github/workflows/lint.yml (1 hunks) </details> <details> <summary>Additional comments not posted (7)</summary><blockquote> <details> <summary>.github/workflows/conventional-commits.yml (2)</summary><blockquote> `13-17`: **Approve the addition of explicit permissions.** Defining explicit permissions for the `build` job enhances security by restricting access to only necessary resources. --- `19-22`: **Approve the improved step naming.** Renaming the steps for clarity enhances the readability of the workflow. </blockquote></details> <details> <summary>.github/workflows/conventional-pull-requests.yml (2)</summary><blockquote> `13-17`: **Approve the addition of explicit permissions.** Defining explicit permissions for the `build` job enhances security by restricting access to only necessary resources. --- `19-21`: **Approve the improved step naming.** Renaming the steps for clarity enhances the readability of the workflow. </blockquote></details> <details> <summary>.github/workflows/lint.yml (3)</summary><blockquote> `13-17`: **Approve the addition of explicit permissions.** Defining explicit permissions for the `build` job enhances security by restricting access to only necessary resources. --- `19-23`: **Approve the checkout step configuration.** The `checkout code` step is correctly configured with `fetch-depth: 0` to ensure the full git history is available for the `super-linter`. --- `24-37`: **Approve the comprehensive `super-linter` configuration.** The `super-linter` is configured to validate multiple code types and automatically fix issues where possible, which helps maintain code quality. </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
.github/workflows/conventional-commits.yml
@ -5,2 +5,4 @@
types: [ opened, synchronize, reopened, edited ]
permissions: { }
coderabbitai[bot] (Migrated from github.com) commented 2024-08-15 11:53:17 +00:00
Copy Link

Define explicit permissions for security.

The addition of an empty permissions block at the top level is unnecessary since specific permissions are already defined within the build job. Consider removing it to avoid confusion.

- permissions: { }
Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
**Define explicit permissions for security.** The addition of an empty `permissions` block at the top level is unnecessary since specific permissions are already defined within the `build` job. Consider removing it to avoid confusion. ```diff - permissions: { } ``` <!-- suggestion_start --> <details> <summary>Committable suggestion</summary> > :bangbang: **IMPORTANT** > Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements. `````suggestion ````` </details> <!-- suggestion_end --> <!-- This is an auto-generated comment by CodeRabbit -->
.github/workflows/conventional-pull-requests.yml
@ -5,2 +5,4 @@
types: [ opened, synchronize, reopened, edited ]
permissions: { }
coderabbitai[bot] (Migrated from github.com) commented 2024-08-15 11:53:17 +00:00
Copy Link

Define explicit permissions for security.

The addition of an empty permissions block at the top level is unnecessary since specific permissions are already defined within the build job. Consider removing it to avoid confusion.

- permissions: { }
Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
**Define explicit permissions for security.** The addition of an empty `permissions` block at the top level is unnecessary since specific permissions are already defined within the `build` job. Consider removing it to avoid confusion. ```diff - permissions: { } ``` <!-- suggestion_start --> <details> <summary>Committable suggestion</summary> > :bangbang: **IMPORTANT** > Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements. `````suggestion ````` </details> <!-- suggestion_end --> <!-- This is an auto-generated comment by CodeRabbit -->
.github/workflows/lint.yml
@ -0,0 +5,4 @@
types: [ opened, synchronize, reopened, edited ]
permissions: { }
coderabbitai[bot] (Migrated from github.com) commented 2024-08-15 11:53:17 +00:00
Copy Link

Define explicit permissions for security.

The addition of an empty permissions block at the top level is unnecessary since specific permissions are already defined within the build job. Consider removing it to avoid confusion.

- permissions: { }
Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
**Define explicit permissions for security.** The addition of an empty `permissions` block at the top level is unnecessary since specific permissions are already defined within the `build` job. Consider removing it to avoid confusion. ```diff - permissions: { } ``` <!-- suggestion_start --> <details> <summary>Committable suggestion</summary> > :bangbang: **IMPORTANT** > Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements. `````suggestion ````` </details> <!-- suggestion_end --> <!-- This is an auto-generated comment by CodeRabbit -->
coderabbitai[bot] (Migrated from github.com) approved these changes 2024-08-15 11:54:54 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
coderabbitai[bot]
Labels
Clear labels
bug
feature
refactor
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: matous-volf/todo-baggins#6
No description provided.
Delete Branch "ci/lint-check"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?