-
Notifications
You must be signed in to change notification settings - Fork 765
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
Visibility lifecycle fixes #746
Conversation
…m-provider-github into test/pull/680
- removes testing of `internal` repositories - we encountered 500s from the API with the following error message: > Only organizations associated with an enterprise can set visibility to internal - a compatible testing environment is needed for automated testing - manual testing may be successful when running a local github instance - removes conflicting use of `private` and `visibility` - added `calculateVisibility` to account for the different combinations of visibility-related configuration that the provider expects - testing revealed different behaviour from the API documentation: > The visibility parameter overrides the private parameter when you use both parameters with the nebula-preview preview header.
- removes testing of `internal` repositories - we encountered 500s from the API with the following error message: > Only organizations associated with an enterprise can set visibility to internal - a compatible testing environment is needed for automated testing - manual testing may be successful when running a local github instance - removes conflicting use of `private` and `visibility` - added `calculateVisibility` to account for the different combinations of visibility-related configuration that the provider expects - testing revealed different behaviour from the API documentation: > The visibility parameter overrides the private parameter when you use both parameters with the nebula-preview preview header.
@jcudit I think this satisfies all of the conditions we talked about earlier this week. What else would you like to see on this PR? I'd be happy to update it with any additional test cases or behavior that you'd like. |
examples/repo_org_internal/cli.cfg
Outdated
provider_installation { | ||
filesystem_mirror { | ||
path = "/Users/jurgen.weber/checkouts/terraform/terraform-provider-github/examples/repo_org_internal/terraform.d/plugins" | ||
include = ["*/*/*"] | ||
} | ||
direct { | ||
exclude = ["*/*/*"] | ||
} | ||
} |
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.
provider_installation { | |
filesystem_mirror { | |
path = "/Users/jurgen.weber/checkouts/terraform/terraform-provider-github/examples/repo_org_internal/terraform.d/plugins" | |
include = ["*/*/*"] | |
} | |
direct { | |
exclude = ["*/*/*"] | |
} | |
} | |
See Building The Provider instructions in CONTRIBUTING.md |
Can we make this more general by pointing to docs in the repo?
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.
Definitely! Would you prefer that we keep this cli.cfg
file the pointer to the repo docs, or maybe should we add a link to the README in that directory? It feels a little weird to me to keep the .cfg
extension for a text or markdown file...what do you think?
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.
add a link to the README in that directory
Good catch! My vote goes to adding a link. https://github.com/integrations/terraform-provider-github/blob/master/CONTRIBUTING.md#building-the-provider addresses this indirectly, so maybe we could link to there.
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.
Done! I've removed the config and provided the link here, and I've also renamed the example directory and created repo name to match the existing pattern in this commit.
How does that look?
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.
Looking great 🚀
* visibility is required on create and can not be updated * add an example * update logic for testing if there is an adequate change * add visibility tests * add testing for creation of private-visibility repos - removes testing of `internal` repositories - we encountered 500s from the API with the following error message: > Only organizations associated with an enterprise can set visibility to internal - a compatible testing environment is needed for automated testing - manual testing may be successful when running a local github instance - removes conflicting use of `private` and `visibility` - added `calculateVisibility` to account for the different combinations of visibility-related configuration that the provider expects - testing revealed different behaviour from the API documentation: > The visibility parameter overrides the private parameter when you use both parameters with the nebula-preview preview header. * add testing for creation of private-visibility repos - removes testing of `internal` repositories - we encountered 500s from the API with the following error message: > Only organizations associated with an enterprise can set visibility to internal - a compatible testing environment is needed for automated testing - manual testing may be successful when running a local github instance - removes conflicting use of `private` and `visibility` - added `calculateVisibility` to account for the different combinations of visibility-related configuration that the provider expects - testing revealed different behaviour from the API documentation: > The visibility parameter overrides the private parameter when you use both parameters with the nebula-preview preview header. * Uncomment tests * Remove specific configuration and instead link to Building the Provider documentation * Renamed example directory to match existing pattern Co-authored-by: Jurgen Weber <jurgen@space-marine.org> Co-authored-by: Jeremy Udit <jcudit@github.com>
This PR unifies the work done in jurgenweber's PR#680 as well as this test branch that some folks were working on.