[wip] refactor Prest config #855

arxdsilva · 2023-12-22T09:21:58Z

todo

decouple adapter from controllers
remove all global config calls
use mockgen pkg on controllers tests
remove need of postgres db started on unit tests
remove old mock pkg
use structy/log widely
fix unit tests
normalize json error output

Moved to v2 Project - will not be covered in this PR:

Summary by CodeRabbit

New Features
- Introduced new adapter interface methods for enhanced database connection management.
- Added functionality to create database adapters from configuration files.
- Implemented a new context function for setting timeouts.
- Launched a plugin system for HTTP processing of .so functions.
- Enhanced JSON response writing with a dedicated function.
Improvements
- Upgraded logging capabilities by replacing fmt with slog package across various commands.
- Refactored database-related functions into methods for better encapsulation.
- Streamlined test suites with consistent naming conventions and mock usage.
- Updated middleware functions to support additional parameters and improved logic.
Bug Fixes
- Corrected the return type of batch insert methods to use the extended Scanner interface.
Documentation
- No visible documentation changes for end-users.
Refactor
- Codebase-wide refactoring to improve structure and maintainability without affecting end-user functionality.
Style
- No visible style changes for end-users.
Tests
- Expanded test coverage to validate new features and refactored components.
Chores
- Updated the Makefile to include a command for generating mock files.
Revert
- No reverts in this release.

coderabbitai · 2023-12-22T09:22:03Z

Important

Auto Review Skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository.

To trigger a single review, invoke the @coderabbitai review command.

Walkthrough

The project underwent a significant refactoring, introducing a more flexible adapter pattern for database interactions, improved testing with mock generation, and a shift from sqlx to database/sql. It also encapsulated configurations within new Config structures, enhanced logging with slog, and streamlined middleware and plugin systems. The interface for scanning database results was extended, and context handling was improved across controllers. Overall, the changes aim for better abstraction, testability, and maintainability.

Changes

File Path	Change Summary
Makefile	Added `mockgen` command for generating mock files.
adapters/...	Expanded `Adapter` interface, added `New` creation function, and tests. Refactored `postgres` adapter implementation.
adapters/mockgen/...	Renamed package to `scanner`, added new methods to `MockAdapter`, and modified code-generated file paths.
cmd/...	Updated commands to use new `cfg` object, replaced `fmt` with `slog` for logging, and removed deprecated calls.
config/config.go	Refactored `Load` function into `New` and `configureViperCmd`, updated `Prest` struct fields.
config/config_test.go	Removed `TestLoad`, updated `TestParse` with new test cases and structure fields.
controllers/...	Introduced `Server` interface and `Config` struct, refactored functions to methods, and improved context handling.
controllers/mockgen/server.go	Added generated GoMock package for server-related methods.
controllers/plugins.go	Added plugin system for `.so` functions.
middlewares/...	Updated middleware functions and tests to use new configuration parameters and logic.
plugins/...	Removed deprecated config imports, added `Config` struct, and updated plugin handling.
router/...	Introduced `Config` type for router setup, renamed and refactored routing functions, added new tests.

"In the warren of code, refactored with care,
🐰 A rabbit hopped through, adding flair everywhere.
With a flip and a hop, new patterns took flight,
Adapters and configs, now snug and just right."

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

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-tests for this file.
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 tests 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 from git and render them as a table.
- @coderabbitai show all the console.log statements in this repository.
- @coderabbitai read src/utils.ts and generate unit tests.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

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 a review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai help to get help.

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

CodeRabbit Configration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
The JSON schema for the configuration file is available here.
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/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

* reduce complexity * remove global config calls * allow easier tests

pull-request-quantifier-deprecated · 2024-01-29T13:02:03Z

This PR has 5489 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +2980 -2509
Percentile : 100%

Total files changed: 76

Change summary by file extension:
.yml : +1 -27
.go : +2970 -2480
.mod : +1 -0
.sum : +3 -0
.toml : +1 -1
Makefile : +4 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-01-29T13:04:25Z

This PR has 5489 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +2980 -2509
Percentile : 100%

Total files changed: 76

Change summary by file extension:
.yml : +1 -27
.go : +2970 -2480
.mod : +1 -0
.sum : +3 -0
.toml : +1 -1
Makefile : +4 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-01-29T13:15:47Z

This PR has 5489 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +2980 -2509
Percentile : 100%

Total files changed: 76

Change summary by file extension:
.yml : +1 -27
.go : +2970 -2480
.mod : +1 -0
.sum : +3 -0
.toml : +1 -1
Makefile : +4 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-01-29T13:15:55Z

This PR has 5489 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +2980 -2509
Percentile : 100%

Total files changed: 76

Change summary by file extension:
.yml : +1 -27
.go : +2970 -2480
.mod : +1 -0
.sum : +3 -0
.toml : +1 -1
Makefile : +4 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-01-30T00:31:49Z

This PR has 5854 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +3332 -2522
Percentile : 100%

Total files changed: 76

Change summary by file extension:
.yml : +1 -27
.go : +3322 -2493
.mod : +1 -0
.sum : +3 -0
.toml : +1 -1
Makefile : +4 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-01-30T03:13:21Z

This PR has 5871 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +3343 -2528
Percentile : 100%

Total files changed: 77

Change summary by file extension:
.yml : +1 -27
.go : +3333 -2499
.mod : +1 -0
.sum : +3 -0
.toml : +1 -1
Makefile : +4 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-10T02:47:35Z

This PR has 5897 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +3369 -2528
Percentile : 100%

Total files changed: 77

Change summary by file extension:
.yml : +1 -27
.go : +3356 -2499
.mod : +1 -0
.sum : +3 -0
.toml : +1 -1
Makefile : +7 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-13T01:53:56Z

This PR has 5935 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +3407 -2528
Percentile : 100%

Total files changed: 77

Change summary by file extension:
.yml : +1 -27
.go : +3394 -2499
.mod : +1 -0
.sum : +3 -0
.toml : +1 -1
Makefile : +7 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated bot added the Extra Large label Dec 22, 2023

arxdsilva had a problem deploying to build December 22, 2023 09:22 — with GitHub Actions Failure

arxdsilva had a problem deploying to build December 22, 2023 09:37 — with GitHub Actions Failure

This was referenced Dec 22, 2023

gen mock files #856

Merged

fix no pg_hba file on startup #857

Merged

arxdsilva force-pushed the server branch from 99f40eb to 1f46b60 Compare December 22, 2023 09:52

arxdsilva had a problem deploying to build December 22, 2023 09:52 — with GitHub Actions Failure

arxdsilva had a problem deploying to build December 24, 2023 02:09 — with GitHub Actions Failure

arxdsilva had a problem deploying to build December 24, 2023 09:22 — with GitHub Actions Failure

arxdsilva had a problem deploying to build December 24, 2023 09:48 — with GitHub Actions Failure

arxdsilva had a problem deploying to build December 24, 2023 20:50 — with GitHub Actions Failure

arxdsilva had a problem deploying to build December 25, 2023 09:13 — with GitHub Actions Failure

arxdsilva had a problem deploying to build December 27, 2023 08:28 — with GitHub Actions Failure

arxdsilva added 16 commits January 9, 2024 03:41

fix initial composer

24a9d62

[wip] refactor Prest config

e2cf4a5

* reduce complexity * remove global config calls * allow easier tests

add mockgen

683b465

update docs

c86cf26

use config on server

7ff448c

refactor controllers config

3cdac9f

fix Test_basicPasswordCheck

316908e

add scanner docs

e9d5270

minor fixes on tests

998ea6f

make servecfg private

387ac68

refactor MiddlewarePlugin

104ee99

fix test_AuthRouteActive

5cefde8

add Test_Route_Databases

f48546a

fix config calls

e0f5f69

fix docs

2efedfe

remove config load

28fbb49

controllers/tables: add Test_GetTablesByDatabaseAndSchema cases

311d23c

arxdsilva had a problem deploying to build January 29, 2024 11:13 — with GitHub Actions Failure

controllers/tables: remove shared errMsg variable

3846882

arxdsilva had a problem deploying to build January 29, 2024 11:20 — with GitHub Actions Failure

arxdsilva added 2 commits January 29, 2024 16:31

controllers/tables: fix http responses

478150a

controllers/tables: add Test_SelectFromTables cases

054e0fe

arxdsilva had a problem deploying to build January 30, 2024 00:31 — with GitHub Actions Failure

cmd: pass context and fix lint

eb27d48

arxdsilva had a problem deploying to build January 30, 2024 03:13 — with GitHub Actions Failure

arxdsilva changed the base branch from main to v2 February 6, 2024 01:16

arxdsilva added 4 commits February 9, 2024 18:29

controllers: update mock

c214553

makefile: update unit test directive

3708d6b

controllers: fix docs

9d70ede

router: start Test_ConfigRoutes

481e1f5

arxdsilva had a problem deploying to build February 10, 2024 02:47 — with GitHub Actions Failure

arxdsilva added 6 commits February 12, 2024 16:55

router: add Test_ConfigRoutes_auth

e325069

router: add Test_ConfigRoutes_databases

4cba550

router: add Test_ConfigRoutes_auth_notFound

4027501

middlewares: skip cache if not enabled

bd06cce

router: add Test_ConfigRoutes_schemas

31bcc57

router: add Test_ConfigRoutes_databases_notFound

507aa93

arxdsilva had a problem deploying to build February 13, 2024 01:53 — with GitHub Actions Failure

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[wip] refactor Prest config #855

[wip] refactor Prest config #855

arxdsilva commented Dec 22, 2023 •

edited

coderabbitai bot commented Dec 22, 2023 •

edited

Auto Review Skipped

Chat

CodeRabbit Commands (invoked as PR comments)

CodeRabbit Configration File (`.coderabbit.yaml`)

CodeRabbit Discord Community

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Jan 30, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Jan 30, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 10, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 13, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

[wip] refactor Prest config #855

Are you sure you want to change the base?

[wip] refactor Prest config #855

Conversation

arxdsilva commented Dec 22, 2023 • edited

todo

Summary by CodeRabbit

coderabbitai bot commented Dec 22, 2023 • edited

Auto Review Skipped

Walkthrough

Changes

Chat

CodeRabbit Commands (invoked as PR comments)

CodeRabbit Configration File (.coderabbit.yaml)

CodeRabbit Discord Community

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Jan 30, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Jan 30, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 10, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 13, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

arxdsilva commented Dec 22, 2023 •

edited

coderabbitai bot commented Dec 22, 2023 •

edited

CodeRabbit Configration File (`.coderabbit.yaml`)