kuberay/.gitignore at master · ray-project/kuberay · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# Ignore backup files.
*~
# Ignore Vim swap files.
**/.*.swp
# Ignore files generated by IDEs.
**/.classpath
**/.factorypath
**/.idea/
**/.ijwb/
**/.project
**/.settings
**/.vscode/
**/bazel.iml
**/.DS_Store
# Ignore all bazel-* symlinks. There is no full list since this can change
# based on the name of the directory bazel is cloned into.
**/bazel-*
# Ignore outputs generated during Bazel bootstrapping.
**/output/
# Ignore jekyll build output.
**/production
**/.sass-cache
# Bazelisk version file
**/.bazelversion
# User-specific .bazelrc
**/user.bazelrc

# Binaries for programs and plugins
**/*.exe
**/*.exe~
**/*.dll
**/*.so
**/*.dylib
**/testbin/*

# Test binary, built with `go test -c`
**/*.test

# Output of the go coverage tool, specifically when used with LiteIDE
**/*.out

**/bin/
# Dependency directories (remove the comment below to include it)
**/vendor/

.ipynb_checkpoints

# Any file with a .backup extension
**/*.backup

# Any file with a .log extension
**/*.log

# Ignore generated CRD schema files
schema/

**/node_modules

# According to Go official documentation (https://go.dev/ref/mod):
#
# "It is generally inadvisable to commit go.work files into version control systems,
# for two reasons:
#
# 1. A checked-in go.work file might override a developer's own go.work file from a
#    parent directory, causing confusion when their use directives don't apply.
#
# 2. A checked-in go.work file may cause a continuous integration (CI) system to
#    select and thus test the wrong versions of a module's dependencies. CI systems
#    should generally not be allowed to use the go.work file so that they can test
#    the behavior of the module as it would be used when required by other modules,
#    where a go.work file within the module has no effect.
#
# That said, there are some cases where committing a go.work file makes sense.
# For example, when the modules in a repository are developed exclusively with
# each other but not together with external modules, there may not be a reason
# the developer would want to use a different combination of modules in a workspace.
# In that case, the module author should ensure the individual modules are tested
# and released properly."
#
# Source: https://go.dev/ref/mod#workspaces
# go.work
# go.work.sum