-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use type awareness in rubygems example #49
Conversation
* configure default values for encrypted data * add built gem to avoid manual building for example purposes * update acra's images version
README.md
Outdated
1. Sign up with any fictional account at [sign_up page](http://www.rubygems.example:8000/sign_up) of the app. That credentials will be used later when uploading gem. | ||
|
||
2. The application we are deploying is gem storage, so we have to build gem that we will use in testing. | ||
2. Verify your email on [special page](http://www.rubygems.example:8000/rails/mailers/mailer/email_confirmation) for development purposes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so the readme says "sign up with fictional account", but then "verify email". so the email should be real?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, you can pass anything you want and the next link for verification specially for test emails to avoid real verification. It provided for development purposes by rubygems project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually, it is not our feature and instructions. all people familiar with that project maybe know or can read the original documentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i understand, just suggesting how to make people's life easier when they are reading the instructions
README.md
Outdated
1. Sign up with any fictional account at [sign_up page](http://www.rubygems.example:8000/sign_up) of the app. That credentials will be used later when uploading gem. | ||
|
||
2. The application we are deploying is gem storage, so we have to build gem that we will use in testing. | ||
2. Verify your email on [special page](http://www.rubygems.example:8000/rails/mailers/mailer/email_confirmation) for development purposes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i understand, just suggesting how to make people's life easier when they are reading the instructions
Co-authored-by: vixentael <[email protected]>
default_data_value: "Tm8gcGVybWlzc2lvbg==" | ||
- column: summary | ||
data_type: bytes | ||
default_data_value: "Tm8gcGVybWlzc2lvbg==" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Github says that there is no newline
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually it doesn't need here. it is end of file
encrypted: | ||
- column: authors | ||
data_type: bytes | ||
# "SGlkZGVuIGF1dGhvcg==" == "Hidden author" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking, maybe we could somehow simplify such configurations for our users? For example, introduce syntax type:data
, which would be used with data_type: bytes
as:
data_type: bytes
default_data_value: text:Hidden author
default_data_value: base64:SGlkZGVuIGF1dGhvcg==
And if not specified, we can use by default one of these. But this is just my thoughts and suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe if we meet such need by ourselves or at least 1-2 user's requests for that - we can discuss it. For now, imho, it will be overengineering due to bytes
will be used rarely in comparison with other types. And we left it more for default_value
feature. But, imho, not much client's need it and they will prefer app's types like int
/str
/etc.
Plus, it complicates configuration. It requires new configuration language over our YAML configuration language over YAML format. For now it's exception for bytes
. If we will provide bytes
/text
, it cause new questions in other parts does this option supports same formatting for values?
, do I need add "text:" for text value for this option?
, and so on.
Should be merged after 0.93.0 release and cossacklabs/acra#525