-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
APIv3 endpoint to manage Environment Variables #5913
APIv3 endpoint to manage Environment Variables #5913
Conversation
@stsewd check it now ;) |
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.
/environmentvariables
seems a little long, but I don't have a better name for it. envvars
? 🤷♂️
'modified', | ||
'name', | ||
'value', | ||
'project', |
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.
do we really need the project here? (haven't seen the other endpoints)
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.
We should just make sure it's the same everywhere, unless we have a good reason (and a code comment)
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.
The project is the main relation with the object(s). I think it's good to have it here. All the other responses also relates with the project.
Actually, VersionSerializer is the only one that does not returns project
. I think I should add it there as well to keep consistency.
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.
Looks good. Agree w/ santos that maybe it's a little long of a field name, but probably better to be explicit here, so I'm +0 on it.
_self = serializers.SerializerMethodField() | ||
project = serializers.SerializerMethodField() | ||
|
||
def get__self(self, obj): |
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.
2 underscsores is weird 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.
Agree. This is because we are using _self
as our attribute since it's kind of a "special name". Then, we need get_
and the attribute...
'modified', | ||
'name', | ||
'value', | ||
'project', |
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.
We should just make sure it's the same everywhere, unless we have a good reason (and a code comment)
@@ -1483,6 +1483,8 @@ class EnvironmentVariable(TimeStampedModel, models.Model): | |||
help_text=_('Project where this variable will be used'), | |||
) | |||
|
|||
objects = RelatedProjectQuerySet.as_manager() |
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.
Did we not need this before? We only appear to be calling all
on it.
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.
Probably we needed it, but nothing was using it to list these related objects.
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.
My feedback was mostly nits, I think we're good to merge.
I agree that it's long, but it's not a bad name to me. |
value
is not shownThis PR is based on #5911 (so, maybe you want to review that one first ;) )