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
Add publicly visible env vars #7891
Conversation
Huh, why is the field not found? I’m adding it in the migration! |
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.
Hi, thanks for the PR!
I left some initial comments about this PR. We may also need to update the APIv3 and its documentation to expose .public
field
I also think that at some point we will want to decide if the env variable will be available only in PRIVATE or PUBLIC versions.
ha! tests work. why doesn’t the migration check though? the output doesn’t speak to me |
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.
Thanks for the PR!
So, in the build process we don't have direct access to the db for security reasons. Instead we get the information we need for the build from the API (v2).
As you have already seen, we use a wrapper class for data returned from the API.
readthedocs.org/readthedocs/projects/models.py
Line 1288 in f18c584
class APIProject(Project): |
To be able to pass only a subset of env variables into the build process (public env vars),
we need to be able to exclude them from the API first.
That's because you changed the model but didn't update the migration, you can delete the migration and generate it again to have it match the changes. |
4c9e68e
to
09fb6e0
Compare
OK, done! Does anything need to be done to have a checkbox to toggle an env var between private and public? |
@flying-sheep as mentioned in my comment (#7891 (review)), you'll need to change the API in order to make this work. The privacy level should be returned in the API, so we can filter them from the builders. readthedocs.org/readthedocs/api/v2/serializers.py Lines 49 to 53 in 7a117b6
|
Not sure to understand. I think we want to set it to readthedocs.org/readthedocs/projects/models.py Lines 1338 to 1343 in db5d9c7
We need to add some tests here for public env vars. And, since the new field is nullable, we need to change the form like this readthedocs.org/readthedocs/projects/forms.py Lines 229 to 231 in a3f3705
|
Let me know if you need more help here, thanks for taking this :) |
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.
@flying-sheep This is looking good to me! We are close to have it merged 😄
Let us know if there is something else you need from our side to wrap up this PR.
All done! |
177e438
to
6c051db
Compare
Ha, got it! The Admin API now still returns all env variables, by calling the method with |
All done! |
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.
👋 Could anyone please have a look? My company could really use this. |
@stsewd I think it's better if we show stars so we keep the message "The value isn't show for security reasons". |
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.
I think this is fine.
I'm not sold on showing the value of the environment variable in any case. CircleCI does not show it either. It shows 4 stars and the last 5 chars of the value.
Regarding the UI, we could copy the pattern we have in other places and only have a listing page (without detail page per variable) with the "Delete" button at the right of each element.
The logic is fine to me and I think we can merge this PR. The UI is going to change in the new theme anyways and I think that @agjohnson already built these pages; so worth to ping him here as well.
It seems that some tests are failing. We should take a look at them as well.
readthedocs/projects/forms.py
Outdated
# Remove the nullable option from the form | ||
self.fields['public'].widget = forms.CheckboxInput() | ||
self.fields['public'].empty_value = False |
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.
Shouldn't we write a data migration that set public=False
to all the existing ones instead?
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.
yeah, but we need to do the migration in the next deploy so we don't have downtime. There are a lot of these missing a migration, may add a PR migrating all of them
public = models.BooleanField( | ||
_('Public'), | ||
default=False, | ||
null=True, |
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.
I think it's better if we write a data migration instead (we can remove the form code as well). This way the data will be valid in our DB.
Yeah, that option is good as well, but the value won't be shown, which I think is fine. |
I went ahead and deleted the detail view, the delete button is on the listing now. |
@humitos let me know what you think now, I can add this to https://github.com/orgs/readthedocs/projects/9 to track the template changes |
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.
@flying-sheep @stsewd looks good to me! 🎉 Thanks! 🙏
@stsewd Please, create a note in the "New theme" project so we can track this.
@flying-sheep thanks for working on this! This should be live by next Tuesday. |
Thank you for helping me figure it all out! How does the rollout work for rtd.org vs rtd.com? Do they get updated in unison? |
yes, we deploy them the same day, first rtd.org and if everything is good we move to rtd.com. |
This is already deployed and it's working. |
I have no idea what I’m doing but maybe this eventually fixes #7413
Also IDK how to restructure the API to support this.
Since
Version
s are always associated with aProject
, maybe the better abstraction would be to add aenvironment_variables
property to theVersion
class. That way we wouldn’t have to doall=version.type != EXTERNAL
in two places but could derive it in the property body.