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
ResourceRegistry is a library for system configuration, feature flipping and eventing. It offers an approach to custom configuration for a single codebase, supporting use cases such as:
8
+
ResourceRegistry is a library for system configuration, feature flipping and eventing. It offers an approach to custom configuration for a single codebase, supporting use cases such as:
10
9
11
10
* Customer-level preference profiles
12
11
* Multitenancy
13
12
* Access control based on privilidges and subscriptions
14
13
15
-
ResourceRegistry is intended to address 'logic sprawl' that can occur with minimally- or un-structured key/value system settings schemes. It offers an
16
-
alternative to code obfuscation issues that often pops up when using Rails Concerns.
14
+
ResourceRegistry is intended to address 'logic sprawl' that can occur with minimally- or un-structured key/value system settings schemes. It offers an alternative to code obfuscation issues that often pops up when using Rails Concerns.
15
+
16
+
**Table of Contents**
17
+
1.[Gem Features](#gem-features)
18
+
2.[Compatibility](#compatibility)
19
+
3.[Installing on Rails](#installing-on-rails)
20
+
4.[Feature](#feature)
21
+
1.[Registering Features](#registering-features)
22
+
2.[Detailed Example](#detailed-example)
23
+
3.[Namepace](#namepace)
24
+
5.[Rails Integration](#rails-integration)
25
+
6.[Configuration](#configuration)
26
+
7.[Development](#development)
27
+
1.[Contributing](#contributing)
28
+
2.[Future Features](#future-features)
29
+
8.[License](#license)
30
+
9.[Credits](#credits)
17
31
18
32
## Gem Features
19
33
@@ -29,31 +43,36 @@
29
43
* Ruby 2.6
30
44
* Rails 5.2.4
31
45
32
-
### Installing on Rails
33
-
34
-
Add this line to your project's Gemfile:
46
+
## Installing on Rails
35
47
48
+
Add this line to your project's Gemfile:
49
+
```
36
50
gem 'resource_registry'
51
+
```
37
52
38
-
And then execute:
39
-
53
+
And then execute:
54
+
```
40
55
$ bundle
56
+
```
41
57
42
-
Or install it yourself as:
43
-
58
+
Or install it yourself as:
59
+
```
44
60
$ gem install resource_registry
61
+
```
45
62
46
-
In your project build the directory tree to house configuration files:
47
-
63
+
In your project build the directory tree to house configuration files:
Use the optional Feature#namespace attribute to organize Features. Namespaces support enable you to define a structure to group Features into a logical structure or taxonomy that can help with code clarity. For example:
172
+
Use the optional Feature#namespace attribute to organize Features. Namespaces support enable you to define a structure to group Features into a logical structure or taxonomy that can help with code clarity. For example:
@@ -178,43 +197,35 @@ Namespaces serve another purpose: enabling auto-generation of Admin UI configura
178
197
179
198
## Rails Integration
180
199
181
-
A registry is configured and loaded when your application starts.
200
+
A registry is configured and loaded when your application starts.
182
201
183
202
## Configuration
184
203
185
-
The initializer and configuration files manage the setup and loading process.
204
+
The initializer and configuration files manage the setup and loading process.
186
205
187
-
Configuration files are located in your project's ```system/config``` directory. All Yaml files in and below this directory are autoloaded during the boot process. Configuration settings may be organized into directories and files in any manner. Values will properly load into the container hierarchy provided the file begins with a reference to an identifiable parent key.
206
+
Configuration files are located in your project's ```system/config``` directory. All Yaml files in and below this directory are autoloaded during the boot process. Configuration settings may be organized into directories and files in any manner. Values will properly load into the container hierarchy provided the file begins with a reference to an identifiable parent key.
188
207
189
-
An example of a simple configuration file:
190
-
```ruby
191
-
# ./system/config/enterprise.yml
208
+
## Development
192
209
193
-
```
210
+
After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
194
211
195
-
## Defining Configuration Settings
212
+
To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
196
213
197
-
### UI-ready configuration settings
214
+
### Contributing
198
215
199
-
## Credits
200
-
Based on [dry-system](https://dry-rb.org/gems/dry-system/) and [dry-validation](https://dry-rb.org/gems/dry-validation/1.0/) ```
216
+
Bug reports and pull requests are welcome on GitHub at https://github.com/ideacrew/resource_registry.
201
217
202
-
## Future Features
218
+
###Future Features
203
219
204
220
* Taxonomy: support namespace structures and validations
205
221
* Subscription
206
222
* Bootable infrastructure components
207
223
208
-
## Development
209
-
210
-
After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
211
-
212
-
To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
224
+
## License
213
225
214
-
## Contributing
226
+
The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).
215
227
216
-
Bug reports and pull requests are welcome on GitHub at https://github.com/ideacrew/resource_registry.
217
228
218
-
## License
229
+
## Credits
219
230
220
-
The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).
231
+
Based on [dry-system](https://dry-rb.org/gems/dry-system/) and [dry-validation](https://dry-rb.org/gems/dry-validation/1.0/)
This file describes the process for publishing a new version of the gem as a GitHub release.
4
+
5
+
Releases are managed through the [GitHub Releases](https://github.com/dchbx/resource_registry/releases) page.
6
+
7
+
Release names follow the [Semantic Versioning](https://semver.org/) standard.
8
+
9
+
Follow the steps below to package and release a new version of the gem.
10
+
11
+
## Major/Minor release
12
+
### Prepare the release
13
+
1. Checkout the main branch and pull the latest changes.
14
+
2. Create and checkout a branch - avoid naming the branch solely after proposed release number - something like 'rm12313453_v1.0.0._update_gemspec' might be ideal.
15
+
3. Update the version number in the `lib/<project>/version.rb` file. Note the [correct format](https://guides.rubygems.org/specification-reference/#version); only digits and dots are allowed. Do not include a `v` prefix.
16
+
4. Update the `Gemfile.lock` file:
17
+
-`bundle update --patch --conservative resource_registry` will generally reduce dependency bumps. Typically, other effects in the lockfile beyond the gem itself being bumped should be discarded.
18
+
- See bundler documentation for detailed information on how this [command](https://bundler.io/v2.5/man/bundle-update.1.html) behaves.
19
+
5. Commit the changes with a message like `bump version to v1.0.0`.
20
+
6. Push the branch and raise a pull request against the main branch. The pull request title should follow the format: `bump version to v1.0.0`. Be sure to label the pull request with the `version-bump` label.
21
+
22
+
### Publishing the Release
23
+
1. Once the pull request is approved and merged, checkout the main branch and pull the latest changes.
24
+
2. Create a new release branch in the pattern of `1.0.x-release`.
25
+
- Note: `x` is literal, to aid reuse of same branch for minor bugfixes.
26
+
3. Create a new annotated tag with the version number, e.g., `git tag -as v1.0.0 -m "v1.0.0"`.
27
+
- IMPORTANT: make sure the tag abides by the format `vX.Y.Z` where `X`, `Y`, and `Z` are integers. It is important that the tag name has a different format than any branch name to avoid confusion with Bundler.
28
+
4. Push the tag to the remote repository, e.g., `git push origin refs/tags/v1.0.0`.
29
+
- Avoid `git push --tags`, to not accidentally push random assorted local tags.
30
+
5. GitHub Actions will automatically create a new release on the [GitHub Releases](https://github.com/dchbx/resource_registry/releases) page with release notes. Confirm that the release was successfully published there and that all intended commits are included in the release.
31
+
32
+
## Patch/Bugfix release
33
+
### Prepare the release
34
+
1. Fix bug in the main branch, via normal PR process.
35
+
36
+
For any release that has the bug:
37
+
2. Create a temp branch off any live release branch that has the bug - pick a name that won't conflict with another branch or tag, as with Major/Minor step 2.
38
+
- Using a branch, which is then PR’d, ensures traceability and inclusion of an item in the generated release notes.
39
+
3. Cherry-pick the fix commits to the temp branch.
40
+
4. Update the gem `version.rb` file and `Gemfile.lock` as in Major/Minor release steps 3 and 4.
41
+
5.`git push` the temp branch.
42
+
6. Issue a PR to merge to the release branch.
43
+
44
+
### Publishing the Release
45
+
1. Once the pull request is approved and merged, checkout the release branch and pull the latest changes.
46
+
2. Create a new annotated tag with the version number, at the point of the release branch with the fix, e.g., `git tag -as v1.0.1 -m "v1.0.1"`.
47
+
3. Push the tag to the remote repository, e.g., `git push origin refs/tags/v1.0.1`.
48
+
- Again, better to avoid `git push --tags`.
49
+
4. Github Actions will create the release and pull in the fix PR's to the changelog.
50
+
51
+
## Using a Tagged Release in Another Project
52
+
To use the new release in another project, update the project's `Gemfile` to reference the release's tag, e.g., `gem 'resource_registry', git: 'https://github.com/dchbx/resource_registry.git', tag: 'v1.0.0'`.
53
+
54
+
## Git Process diagram
55
+
0 commit comments