Conversation
|
|
||
| dir := usrCfg.GetString("workspace") | ||
| if solution.Team != "" { | ||
| dir = filepath.Join(dir, "teams", solution.Team) |
There was a problem hiding this comment.
This is a bit confusing. In payload it is a struct here Team is a string. I understand the difference but maybe it should be TeamSlug. Or maybe have a different name in the Solution struct
There was a problem hiding this comment.
Yeah, I think TeamSlug makes sense.
There was a problem hiding this comment.
I changed it back, actually.
In the solution we're storing just the minimal metadata. The payload has more data about both the track and the team, which we can use to communicate about it if we want to.
I would rather change the solution type later to have a more fleshed out team than to call this TeamSlug now.
nywilken
left a comment
There was a problem hiding this comment.
I started looking through this and structurally it makes sense. It needs to be rebased with the latest changes made to the download command. I took a bit longer with the other PRs so I will get to this one later today.
|
Yeah, I submitted small parts of this as other PRs, so I need to rework it so it's just the smallest possible change. |
|
I think this is ready for another round of review. I've cleaned it up and the PR is as small as I can get it and still be a coherent change :) |
|
Wait. The first two commits are in a separate PR already (#676). Hold off on reviewing this until the other PR is merged, then I'll rebase and this will be smaller. |
So If I understand correctly, you can not submit a solution to your team unless you download it with the team flag. Is that correct? If so do we need to handle the case where a user is trying to submit for a team but has none. If that is the case what should be the expected use case when I do the following Since the team flag is not provided should it remove the team property from the solution file? |
821d5ec to
b268ce8
Compare
|
Ok, merged the previous PR and rebased this one. Should be good to review! |
This updates the fake server to fill in the teams in the payload if the team flag is passed. Nothing is passing the team flag yet.
| Track string `json:"track"` | ||
| Exercise string `json:"exercise"` | ||
| ID string `json:"id"` | ||
| Team string `json:"team,omitempty"` |
There was a problem hiding this comment.
what is the intended empty state for Team “”, null? I ask because I am wondering if this should be of type *string.
If the empty state is “” then your example of “null” in the test should be changed.
There was a problem hiding this comment.
The empty state of the solution metadata is "". The empty state of the payload we receive from the server is null.
|
|
||
| payloadBody := fmt.Sprintf(payloadTemplate, requestor, server.URL+"/") | ||
| mux.HandleFunc("/solutions/latest", func(w http.ResponseWriter, r *http.Request) { | ||
| team := "null" |
There was a problem hiding this comment.
See my comment about the Team field for the Solution type.
nywilken
left a comment
There was a problem hiding this comment.
This looks good in its current state. I was concerned about the data, but since it is being controlled via the API we don’t have to account for edge cases in the data, but we can easily adapt if needed.
|
Thank you! |
We're working on implementing teams, which is pretty different from how it worked on the old site. In short, teams are a whole separate thing. If you are working on
bobin Python on the main site, and you're a member of a team, then yourbobdoes not automatically end up in the team pool of solutions. You need to explicitly submit it with a--teamflag (not yet implemented in the CLI). Likewise, to work on an exercise for a team, you need to download it so that you get the correct metadata, then you can copy over your solution from your main track.Closes #546