Skip to content
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

Merged

Conversation

humitos
Copy link
Member

@humitos humitos commented Jul 11, 2019

  • allow create/delete/list/detail Environment Variables
  • it's not allowed to modify them, similar to the WebUI
  • the value is not shown
  • it follows the same idea than Redirects endpoint

This PR is based on #5911 (so, maybe you want to review that one first ;) )

@humitos humitos requested a review from a team July 11, 2019 16:37
@stsewd
Copy link
Member

stsewd commented Jul 11, 2019

@humitos the base branch in #5911 is in the same rep, so you can change the base branch here to point to the other one, so we have a better diff.

@humitos humitos changed the base branch from master to humitos/apiv3-split-tests July 11, 2019 16:44
@humitos
Copy link
Member Author

humitos commented Jul 11, 2019

@stsewd check it now ;)

Copy link
Member

@stsewd stsewd left a 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',
Copy link
Member

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)

Copy link
Member

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)

Copy link
Member Author

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.

Copy link
Member

@ericholscher ericholscher left a 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):
Copy link
Member

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.

Copy link
Member Author

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',
Copy link
Member

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()
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

@ericholscher ericholscher left a 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.

@humitos
Copy link
Member Author

humitos commented Jul 16, 2019

/environmentvariables seems a little long, but I don't have a better name for it. envvars? man_shrugging

I agree that it's long, but it's not a bad name to me. envvars is shorter but worse :) . Also, I think it's not something that you will have to type many times and where you want to be descriptive in short to avoid typing (like in a variable name).

@humitos humitos merged commit 82347f3 into humitos/apiv3-split-tests Jul 16, 2019
@delete-merged-branch delete-merged-branch bot deleted the humitos/apiv3-environmentvariables branch July 16, 2019 09:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants