-
Notifications
You must be signed in to change notification settings - Fork 182
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
doc more opts #480
doc more opts #480
Conversation
Closes #439 Relates #220 (comment) Resolves #220 Resolves #420 Resolves #458
archived: false | ||
|
||
# Can be `public`, `private` or `internal` | ||
visibility: public |
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.
does this conflict with the existing private
attribute? is the use of private
vs visibility
mutually exclusive?
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.
they are different and it depends whether you are github enterprise user and what is the organization (within the enterprise) policy.
e.g. the organization set the default repository visibility to private, even if one will use private: false
it won't affect the organization policy. yet, you can set visibility
to internal
or private
.
here are some references for clarity (i don't want to copy and paste):
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 guess what i'm getting at is that i think we should clarify what happens when both private
and visibility
are defined together and maybe discourage defining both. from https://docs.github.com/en/rest/reference/repos#update-a-repository:
The visibility parameter overrides the private parameter when you use both along with the nebula-preview preview header.
and it depends whether you are github enterprise user and what is the organization (within the enterprise) policy.
i think this is the other piece that should be mentioned here since internal
doesnt apply in all cases. again from https://docs.github.com/en/rest/reference/repos#update-a-repository, i like the way that is described:
Can be public or private. If your organization is associated with an enterprise account using GitHub Enterprise Cloud or GitHub Enterprise Server 2.20+, visibility can also be internal.
this documents a bit more than i was expecting from #458. i'm all for documenting each of these, but want to confirm a couple of things before we move forward.
|
yes
no, otherwise i would have reported an issue :)
from many playing around, they are not required and one who does not use these options\keys will have the default github settings of the repository (again, such settings might be inherited from the github organization policy) |
Hi @travi, did I answer all of your questions? Is there a need for a further clarification? |
@travi, any feedback? |
Please be patient. This is still on my list. I just haven't gotten back to it yet. |
archived: false | ||
|
||
# Can be `public`, `private` or `internal` | ||
visibility: public |
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 guess what i'm getting at is that i think we should clarify what happens when both private
and visibility
are defined together and maybe discourage defining both. from https://docs.github.com/en/rest/reference/repos#update-a-repository:
The visibility parameter overrides the private parameter when you use both along with the nebula-preview preview header.
and it depends whether you are github enterprise user and what is the organization (within the enterprise) policy.
i think this is the other piece that should be mentioned here since internal
doesnt apply in all cases. again from https://docs.github.com/en/rest/reference/repos#update-a-repository, i like the way that is described:
Can be public or private. If your organization is associated with an enterprise account using GitHub Enterprise Cloud or GitHub Enterprise Server 2.20+, visibility can also be internal.
@@ -72,6 +72,18 @@ repository: | |||
# vulnerability alerts. | |||
enable_vulnerability_alerts: true | |||
|
|||
# Either `true` to make this repo available as a template repository or `false` to prevent it. | |||
# is_template: false | |||
# template_repository: false |
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 see is_template
listed on https://docs.github.com/en/rest/reference/repos#update-a-repository, but i dont find template_repository
mentioned there. were both intentionally included here?
also, is there a reason that this one is commented out?
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.
you can see it on https://docs.github.com/en/rest/reference/repos#list-organization-repositories
The is_template and template_repository keys are currently available for developer to preview.
@@ -146,6 +158,8 @@ branches: | |||
strict: true | |||
# Required. The list of status checks to require in order to merge into this branch | |||
contexts: [] | |||
# Commits pushed to matching branches must have verified signatures. Set to false to disable. | |||
required_signatures: true |
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 dont find this attribute mentioned in the docs at https://docs.github.com/en/rest/reference/repos#update-branch-protection
did you find details about this one somewhere else?
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.
found it on https://docs.github.com/en/rest/reference/repos#create-commit-signature-protection
and although i am writing it in this comment, all new addition have been tested.
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.
You can also find earlier confirmation of @foolioo's statement in this comment
@@ -155,6 +169,12 @@ branches: | |||
apps: [] | |||
users: [] | |||
teams: [] | |||
# Permits force pushes for all users with push access. Set to null to disable. | |||
allow_force_pushes: |
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 value is provided here
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 value is considered null
, same as https://github.com/foolioo/settings/blob/4250d82870301f6df716780ddc90a50a0540e98f/README.md#L141
@@ -155,6 +169,12 @@ branches: | |||
apps: [] | |||
users: [] | |||
teams: [] | |||
# Permits force pushes for all users with push access. Set to null to disable. |
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 dont think "disable" makes sense for this one
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.
to which world would you like to change it?
# Permits force pushes for all users with push access. Set to null to disable. | ||
allow_force_pushes: | ||
# Allows users with push access to delete matching branches. Set to false to disable. | ||
allow_deletions: false |
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.
disable doesnt really make sense for this one either
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 only kept the same terminology. although there are many places when disable
was used, would you like to change "disable" to "disallow"?
https://github.com/foolioo/settings/blob/4250d82870301f6df716780ddc90a50a0540e98f/README.md#L36
https://github.com/foolioo/settings/blob/4250d82870301f6df716780ddc90a50a0540e98f/README.md#L39
https://github.com/foolioo/settings/blob/4250d82870301f6df716780ddc90a50a0540e98f/README.md#L43
https://github.com/foolioo/settings/blob/4250d82870301f6df716780ddc90a50a0540e98f/README.md#L46
https://github.com/foolioo/settings/blob/4250d82870301f6df716780ddc90a50a0540e98f/README.md#L141
...
@travi: Shall we give this PR another push for the sake of getting it done before it becomes stale? |
Your work, knowledge sharing and dedication are very appreciated, especially when you do that for free. If you need a hand in maintaining Probot Setting project, I am offering myself as your apprentice - maybe I could assist you in progressing things you like less or things in a lower priority, so the community could earn back your precious time. |
apologies for continued delay here. the last few weeks have been especially busy for me. i havent been entirely ignoring you, though. the comments that i had above got me thinking further about this project's documentation that i've been considering for a while. basically, i think we need to avoid duplicating documentation that already exists for the api. instead, we should make it more clear that the api documentation is an appropriate reference for the details that can be managed by the settings app. that will help us avoid wording that doesnt quite align with the details outlined by the github technical writing staff, but will also help us avoid the situation where new properties are available from the api that we havent yet added to our examples. i've started working on some updates to our docs that i think will help make this more clear. examples will still be provided, but it will be more clear that they are not going to include all properties or full descriptions of all that we do include. that said, i think there are two options for this pr. either we can simplify to the single property that was asked for in #458 so that we can avoid resolving some of the other questions for now, or we can wait until after the restructuring that i'm working on before we decide which additional details would provide value beyond referencing the api documentation. |
Thank you @travi for sharing your thoughts.
I think we have it... https://github.com/probot/settings/blob/2a2e9333ed68c8dc9962add9d9b9228d7f2c7821/README.md#L19 |
@travi i think we should try to merge this pull-request since it solves many "issues". do you think we should try to merge or close the pull-request? |
@travi would you like to merge these changes or would you like to close the pull-request? |
Friendly ping @travi |
i'm trying to consider what to suggest for this PR after #893. at minimum, this will need to be adjusted to the updated format of the configuration documentation if we decide to include these updates. however, before investing more effort, lets come to agreement on the below thoughts: i'm struggling with the value of continuing to add properties to the example. new properties are constantly being added to the api, so being complete in the examples is a losing battle. plus, the examples are meant to be examples with a reference to where to get the complete, official details. i dont intend for the examples to be complete. i do appreciate the time you've invested in this and i do see value in highlighting certain parts, especially where there might be some confusion that isn't well clarified by the official docs. however, i could use some help deciding what is valuable to include here that isnt just taking the docs closer to completeness rather than examples with official docs references |
#893 is a bliss. this pr came after browsing the issues and seeing lots of repeated questions about the configuration (since most don't rtfm), which leads to comments such as #567 (comment). i think we can close this pr. if you think otherwise, please do reopen. |
Per @travi request
Resolves #439
Relates #220 (comment)
Resolves #220
Resolves #420
Resolves #458
Resolves #359
Resolves #402
View rendered README.md