You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Minor changes can be done directly by editing code on GitHub. GitHub automatically creates a temporary branch and
2
+
* Minor changes can be done directly by editing code on GitHub. GitHub automatically creates a temporary branch and
4
3
files a PR. This is only suitable for really small changes like: spelling fixes, variable name changes or error string
5
4
change etc. For larger commits, following steps are recommended.
6
-
- (Optional) If you want to discuss your implementation with the users of GoFr, use the GitHub discussions of this repo.
7
-
- Configure your editor to use goimport and golangci-lint on file changes. Any code which is not formatted using these
5
+
* (Optional) If you want to discuss your implementation with the users of GoFr, use the GitHub discussions of this repo.
6
+
* Configure your editor to use goimport and golangci-lint on file changes. Any code which is not formatted using these
8
7
tools, will fail on the pipeline.
9
-
- Contributors should begin working on an issue only after it has been assigned to them. To get an issue assigned, please comment on the GitHub thread
8
+
* Contributors should begin working on an issue only after it has been assigned to them. To get an issue assigned, please comment on the GitHub thread
10
9
and request assignment from a maintainer. This helps avoid duplicate or conflicting pull requests from multiple contributors.
11
-
- Issues labeled triage are not open for direct contributions. If you're interested in working on a triage issue, please reach out to the maintainers
12
-
to discuss it before proceeding in the Github thread.
10
+
* Issues labeled triage are not open for direct contributions. If you're interested in working on a triage issue, please reach out to the maintainers
11
+
to discuss it before proceeding in the Github thread.
13
12
<!-- spellchecker:off "favour" have to be ignored here -->
14
-
- We follow **American English** conventions in this project (e.g., _"favor"_ instead of _"favour"_). Please keep this consistent across all code comments, documentation, etc.
13
+
* We follow **American English** conventions in this project (e.g., *"favor"* instead of *"favour"*). Please keep this consistent across all code comments, documentation, etc.
15
14
<!-- spellchecker:on -->
16
-
- All code contributions should have associated tests and all new line additions should be covered in those testcases.
15
+
* All code contributions should have associated tests and all new line additions should be covered in those testcases.
17
16
No PR should ever decrease the overall code coverage.
18
-
- Once your code changes are done along with the testcases, submit a PR to development branch. Please note that all PRs
17
+
* Once your code changes are done along with the testcases, submit a PR to development branch. Please note that all PRs
19
18
are merged from feature branches to development first.
20
-
21
19
* PR should be raised only when development is complete and the code is ready for review. This approach helps reduce the number of open pull requests and facilitates a more efficient review process for the team.
22
20
* All PRs need to be reviewed by at least 2 GoFr developers. They might reach out to you for any clarification.
23
21
* Thank you for your contribution. :)
@@ -30,28 +28,32 @@ Testing is a crucial aspect of software development, and adherence to these guid
30
28
31
29
1.**Test Types:**
32
30
33
-
- Write unit tests for every new function or method.
34
-
- Include integration tests for any major feature added.
31
+
-Write unit tests for every new function or method.
32
+
-Include integration tests for any major feature added.
35
33
36
-
2.**Test Coverage:**
37
34
38
-
- No new code should decrease the existing code coverage for the packages and files.
39
-
> The `code-climate` coverage check will not pass if there is any decrease in the test-coverage before and after any new PR is submitted.
35
+
2.**Test Coverage:**
40
36
41
-
3.**Naming Conventions:**
37
+
- No new code should decrease the existing code coverage for the packages and files.
38
+
> The `code-climate` coverage check will not pass if there is any decrease in the test-coverage before and after any new PR is submitted.
42
39
43
-
- Prefix unit test functions with `Test`.
44
-
- Use clear and descriptive names.
45
40
41
+
42
+
3.**Naming Conventions:**
43
+
44
+
- Prefix unit test functions with `Test`.
45
+
- Use clear and descriptive names.
46
46
```go
47
47
funcTestFunctionName(t *testing.T) {
48
48
// Test logic
49
49
}
50
50
```
51
51
52
+
53
+
52
54
4.**Table-Driven Tests:**
53
55
54
-
- Consider using table-driven tests for testing multiple scenarios.
56
+
-Consider using table-driven tests for testing multiple scenarios.
55
57
56
58
> [!NOTE]
57
59
> Some services will be required to pass the entire test suite. We recommend using docker for running those services.
> Please note that the recommended local port for the services are different from the actual ports. This is done to avoid conflict with the local installation on developer machines. This method also allows a developer to work on multiple projects which uses the same services but bound on different ports. One can choose to change the port for these services. Just remember to add the same in configs/.local.env, if you decide to do that.
106
108
107
-
### Coding Guidelines
108
109
109
-
- Use only what is given to you as part of function parameter or receiver. No globals. Inject all dependencies including
110
+
### Coding Guidelines
111
+
* Use only what is given to you as part of function parameter or receiver. No globals. Inject all dependencies including
110
112
DB, Logger etc.
111
-
- No magic. So, no init. In a large project, it becomes difficult to track which package is doing what at the
113
+
* No magic. So, no init. In a large project, it becomes difficult to track which package is doing what at the
112
114
initialization step.
113
-
- Exported functions must have an associated godoc.
114
-
- Sensitive data(username, password, keys) should not be pushed. Always use environment variables.
115
-
- Take interfaces and return concrete types.
116
-
- Lean interfaces - take 'exactly' what you need, not more. Onus of interface definition is on the package who is
117
-
using it. so, it should be as lean as possible. This makes it easier to test.
118
-
- Be careful of type assertions in this context. If you take an interface and type assert to a type - then it's
119
-
similar to taking concrete type.
120
-
- Uses of context:
121
-
- We should use context as a first parameter.
122
-
- Can not use string as a key for the context. Define your own type and provide context accessor method to avoid
123
-
conflict.
124
-
- External Library uses:
125
-
- A little copying is better than a little dependency.
126
-
- All external dependencies should go through the same careful consideration, we would have done to our own written
127
-
code. We need to test the functionality we are going to use from an external library, as sometimes library
128
-
implementation may change.
129
-
- All dependencies must be abstracted as an interface. This will make it easier to switch libraries at later point
130
-
of time.
131
-
- Version tagging as per Semantic versioning (https://semver.org/)
115
+
* Exported functions must have an associated godoc.
116
+
* Sensitive data(username, password, keys) should not be pushed. Always use environment variables.
117
+
* Take interfaces and return concrete types.
118
+
- Lean interfaces - take 'exactly' what you need, not more. Onus of interface definition is on the package who is
119
+
using it. so, it should be as lean as possible. This makes it easier to test.
120
+
- Be careful of type assertions in this context. If you take an interface and type assert to a type - then it's
121
+
similar to taking concrete type.
122
+
* Uses of context:
123
+
- We should use context as a first parameter.
124
+
- Can not use string as a key for the context. Define your own type and provide context accessor method to avoid
125
+
conflict.
126
+
* External Library uses:
127
+
- A little copying is better than a little dependency.
128
+
- All external dependencies should go through the same careful consideration, we would have done to our own written
129
+
code. We need to test the functionality we are going to use from an external library, as sometimes library
130
+
implementation may change.
131
+
- All dependencies must be abstracted as an interface. This will make it easier to switch libraries at later point
132
+
of time.
133
+
* Version tagging as per Semantic versioning (https://semver.org/)
132
134
133
135
### Documentation
134
-
135
-
- After adding or modifying existing code, update the documentation too - [development/docs](https://github.com/gofr-dev/gofr/tree/development/docs).
136
-
- When you consider a new documentation page is needed, start by adding a new file and writing your new documentation. Then - add a reference to it in [navigation.js](https://gofr.dev/docs/navigation.js).
137
-
- If needed, update or add proper code examples for your changes.
138
-
- In case images are needed, add it to [docs/public](./docs/public) folder.
139
-
- Make sure you don't break existing links and references.
140
-
- Maintain Markdown standards, you can read more [here](https://www.markdownguide.org/basic-syntax/), this includes:
141
-
- Headings (`#`, `##`, etc.) should be placed in order.
142
-
- Use trailing white space or the <br> HTML tag at the end of the line.
143
-
- Use "`" sign to add single line code and "```" to add multi-line code block.
144
-
- Use relative references to images (in `public` folder as mentioned above.)
145
-
- The [gofr.dev documentation](https://gofr.dev/docs) site is updated upon push to `/docs` path in the repo. Verify your changes are live after next GoFr version.
136
+
* After adding or modifying existing code, update the documentation too - [development/docs](https://github.com/gofr-dev/gofr/tree/development/docs).
137
+
* When you consider a new documentation page is needed, start by adding a new file and writing your new documentation. Then - add a reference to it in [navigation.js](https://gofr.dev/docs/navigation.js).
138
+
* If needed, update or add proper code examples for your changes.
139
+
* In case images are needed, add it to [docs/public](./docs/public) folder.
140
+
* Make sure you don't break existing links and references.
141
+
* Maintain Markdown standards, you can read more [here](https://www.markdownguide.org/basic-syntax/), this includes:
142
+
- Headings (`#`, `##`, etc.) should be placed in order.
143
+
- Use trailing white space or the <br> HTML tag at the end of the line.
144
+
- Use "`" sign to add single line code and "```" to add multi-line code block.
145
+
- Use relative references to images (in `public` folder as mentioned above.)
146
+
* The [gofr.dev documentation](https://gofr.dev/docs) site is updated upon push to `/docs` path in the repo. Verify your changes are live after next GoFr version.
Copy file name to clipboardExpand all lines: docs/advanced-guide/handling-file/page.md
+8-2Lines changed: 8 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,12 @@ GoFr simplifies the complexity of working with different file stores by offering
6
6
7
7
By default, local file-store is initialized and user can access it from the context.
8
8
9
-
GoFr also supports FTP/SFTP file-store. Developers can also connect and use their AWS S3 bucket or Google Cloud Storage (GCS) bucket as a file-store. The file-store can be initialized as follows:
9
+
GoFr also supports FTP/SFTP file-store. Developers can also connect and use their cloud storage bucket as a file-store. Following cloud storage options are currently supported:
The `RemoveAll` command deletes all subdirectories as well. If you delete the current working directory, such as "../currentDir", the working directory will be reset to its parent directory.
309
314
310
-
> Note: In S3 and GCS, RemoveAll only supports deleting directories and will return an error if a file path (as indicated by a file extension) is provided for S3. GCS handles both files and directories.
315
+
> Note: In S3, RemoveAll only supports deleting directories and will return an error if a file path (as indicated by a file extension) is provided for S3.
0 commit comments