[WIP]Add support of GitHub as deployment option#1121
Conversation
1. Add update operation for source_control and external_scm_credential. 2. Refactor the code logic of expand and flatten functions.
tombuildsstuff
left a comment
There was a problem hiding this comment.
hey @metacpp
I've taken a look through and left some comments in-line - before proceeding any further (e.g. tests/docs etc) with this PR we should focus on working out how the schema needs to look, in particular I don't believe we need the external_scm_credentials block at all since it can be in-lined into the VCS URI?
Thanks!
|
|
||
| "source_control": { | ||
| Type: schema.TypeList, | ||
| Optional: true, |
There was a problem hiding this comment.
neither of these fields can currently be specified by the user, so there's no need to make this optional at the moment?
There was a problem hiding this comment.
In GitHub scenario, you need to specify the repo URL and branch name for Azure Web App to consume. It's not the same scenario as LocalGit, which will automatically generate the SCM URL hosted on Azure web app. I will update the example usage for GitHub scenario, then you will know what's the workflow.
| }, | ||
| }, | ||
|
|
||
| "external_scm_credential": { |
There was a problem hiding this comment.
I don't believe we don't need a separate block for this - as mentioned in this comment it can be part of the Repository URI in the source_control block, which will cover all cases. As such - can we remove this?
There was a problem hiding this comment.
This is to allow end-user to set personal access token which will authorize Azure web app to access repo and org information through API way. In other words, this is the token required by Azure to integrate with any 3rd party deployment options.
We may have a better naming here, what's your suggestion ?
| "name": { | ||
| Type: schema.TypeString, | ||
| Computed: true, | ||
| Default: "GitHub", |
There was a problem hiding this comment.
in cases such as this (where this is within an Optional sub-object) - we can make this Required. We should also remove the Default value and Computed here, since it needs to be user specified
| } | ||
|
|
||
| func flattenAppServiceSiteCredential(input *web.UserProperties) []interface{} { | ||
| func flattenAppServiceSiteCredential(input *web.User) []interface{} { |
There was a problem hiding this comment.
we should be pulling from the UserProperties object since the non-Properties object isn't actually valid in Azure (e.g. it doesn't actually match the schema and can be nil in older configurations)
There was a problem hiding this comment.
User is using embedding with UserProperties, you can directly access any field in User object.
| return scmRet | ||
| } | ||
|
|
||
| func flattenAppServiceSourceControl(input *web.SiteSourceControl) []interface{} { |
There was a problem hiding this comment.
we should be pulling from the SiteSourceControlProperties object since the non-Properties object isn't actually valid in Azure (e.g. it doesn't actually match the schema and can be nil in older configurations)
There was a problem hiding this comment.
Internal Go SDK is using SiteSourceControl as returned type and SiteSourceControlProperties is embedded class, which means that you can access all the fields in SiteSourceControl. It's meaningless to do any kind of de-referencing before flattening.
I don't understand what's your concern here, maybe a more concrete example ?
There was a problem hiding this comment.
at this point in time, from memory that representation has changed in the past such that the top level can be nil vs the properties object being populated - that's not how it's represented in the JSON Response so we should match that where possible (which we do throughout the provider)
There was a problem hiding this comment.
There's no any API return SiteSourceControlProperties, instead, it's SiteSourceControl.
If SiteSourceControl is nil, then you will not be able to get SiteSourceControlProperties, since they're the same object but different layer.
|
@tombuildsstuff external_scm_credential is personal access token used by azure behind the scene to access org and repo information. It's not like the azure its own repo, there's no chance for any CI pipeline to directly access the repo hosted on GitHub. It's completely different scenario. |
|
And for the personal token type, we have weak dependency on #2946 |
|
@metacpp what's the status of this PR - it's been a |
|
@metacpp since we've not heard back from you here (and there's merge conflicts) - I'm going to close this PR for the moment; please feel free to re-open it if this is being actively worked on. Thanks! |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks! |
Still work in progress
Support GitHub as deployment option for azure web app, the workflow will be:
Will add example usage and tests in this PR very soon.