Closed jan-zabloudil closed 3 months ago
But in #109 I can see that chances are, in case of Release
, GitHub Release fields might end up simply a part of Release
model, and splitted out later on, together with db layer.
In this case, consider employing the same principle also here, i.e. GithubOwnerSlug
, GithubRepoSlug
and (potentially) dynamically generated GithubRepoURL
simply as a part of Project
model. 👌
I will stick with separate struct here:
I can simply pass the struct from github client:
func (c *Client) GetGithubRepoFromRawURL(rawURL string) (svcmodel.GithubRepo, error) {
I can easily check if github repo is set:
projects.GithubRepo != nil
.....
I have realized it will be much more convenient to have a
GithubRepo
struct (which will contain parsed slugs) in the service model (and consequently in the repository model).Why? Because when handling webhook requests, slugs will be provided as the repository identifier. This will simplify the process, i could directly do:
In this PR, I only demonstrate how it would be implemented. If you like this approach, I will also update the repository model and modify the GitHub client methods to accept
svcmodel.GithubRepo
instead of URLs, etc.I believe this is also a good step towards the larger GitHub refactoring. After the refactoring, you will have a separate entity for the GitHub repository identifier (such as slugs etc.)