-
Notifications
You must be signed in to change notification settings - Fork 7
Document development conventions for config vars #620
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
base: master
Are you sure you want to change the base?
Conversation
Added development conventions for config variables in env.local.
Clarified documentation for adding and modifying config vars in env.local, emphasizing user-friendly practices and backward compatibility.
Clarify development conventions to enhance user experience and minimize update friction.
E2E Test ResultsDACCS-iac Pipeline ResultsBuild URL : http://daccs-jenkins.crim.ca:80/job/DACCS-iac-birdhouse/3903/Result ❌ FAILUREBIRDHOUSE_DEPLOY_BRANCH : document-dev-convention DACCS_IAC_BRANCH : master DACCS_CONFIGS_BRANCH : master PAVICS_E2E_WORKFLOW_TESTS_BRANCH : master PAVICS_SDI_BRANCH : master DESTROY_INFRA_ON_EXIT : true PAVICS_HOST : https://host-140-216.rdext.crim.ca PAVICS-e2e-workflow-tests Pipeline ResultsTests URL : http://daccs-jenkins.crim.ca:80/job/PAVICS-e2e-workflow-tests/job/master/579/NOTEBOOK TEST RESULTS |
E2E Test ResultsDACCS-iac Pipeline ResultsBuild URL : http://daccs-jenkins.crim.ca:80/job/DACCS-iac-birdhouse/3904/Result ❌ FAILUREBIRDHOUSE_DEPLOY_BRANCH : document-dev-convention DACCS_IAC_BRANCH : master DACCS_CONFIGS_BRANCH : master PAVICS_E2E_WORKFLOW_TESTS_BRANCH : master PAVICS_SDI_BRANCH : master DESTROY_INFRA_ON_EXIT : true PAVICS_HOST : https://host-140-91.rdext.crim.ca PAVICS-e2e-workflow-tests Pipeline ResultsTests URL : http://daccs-jenkins.crim.ca:80/job/PAVICS-e2e-workflow-tests/job/master/580/NOTEBOOK TEST RESULTS |
E2E Test ResultsDACCS-iac Pipeline ResultsBuild URL : http://daccs-jenkins.crim.ca:80/job/DACCS-iac-birdhouse/3905/Result ❌ FAILUREBIRDHOUSE_DEPLOY_BRANCH : document-dev-convention DACCS_IAC_BRANCH : master DACCS_CONFIGS_BRANCH : master PAVICS_E2E_WORKFLOW_TESTS_BRANCH : master PAVICS_SDI_BRANCH : master DESTROY_INFRA_ON_EXIT : true PAVICS_HOST : https://host-140-154.rdext.crim.ca PAVICS-e2e-workflow-tests Pipeline ResultsTests URL : http://daccs-jenkins.crim.ca:80/job/PAVICS-e2e-workflow-tests/job/master/581/NOTEBOOK TEST RESULTS |
| is only an example and can not count as a default value. | ||
|
|
||
| * **Documentation** for the new var can be both in ``default.env`` and ``env.local.example`` to be | ||
| most user-friendly. If you do not wish to duplicate the info because it is big, you can put in one of |
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 we need to choose which one we prefer. I would say that we should always prefer env.local.example for variables that are use facing and default.env for the internal-only variables.
| the two files and reference in the other file. | ||
|
|
||
| * Documenting in ``env.local.example`` is the most user-friendly for new user starting out because they | ||
| will have to copy ``env.local.example`` to ``env.local``. |
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.
| will have to copy ``env.local.example`` to ``env.local``. | |
| will refer to ``env.local.example`` when writing their local environment file. |
(we're trying to distinguish between the "local environment file" and env.local which is the default location of that file)
| from the same component. Some vars/documentations are "dangerous" so we do not even expose them to | ||
| ``env.local.example``. |
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.
| from the same component. Some vars/documentations are "dangerous" so we do not even expose them to | |
| ``env.local.example``. | |
| from the same component. Some variables are for internal use only and should not be modified by the user. This means we should not document them in ``env.local.example``. |
| * **Naming convention** should be ``<COMPONENT_NAME>_<VAR_NAME>`` to avoid name clash. For platform vars | ||
| that do not belong to any components, use ``BIRDHOUSE`` prefix instead of ``<COMPONENT_NAME>``. | ||
|
|
||
| Renaming or deleting an existing config var in ``env.local`` |
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.
| Renaming or deleting an existing config var in ``env.local`` | |
| Renaming or deleting an existing configuration variable |
| * Try to **avoid** this scenario as this is **backward incompatible** with all existing ``env.local`` on | ||
| all existing deployments. |
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.
| * Try to **avoid** this scenario as this is **backward incompatible** with all existing ``env.local`` on | |
| all existing deployments. | |
| * Try to **avoid** this scenario as this is **backward incompatible** without requiring existing deployments to manually update their local environment files. |
| * **Document migration path** clearly in ``CHANGES.md``. | ||
|
|
||
| * Bump **minor** version, **not patch** version on release to signal **backward incompatible** change | ||
| requiring manual update to all existing ``env.local`` on all existing deployments. |
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.
Also mention that they should add an entry to docs/source/migration_guide.rst
| * Bump **minor** version, **not patch** version on release to signal **backward incompatible** change | ||
| requiring manual update to all existing ``env.local`` on all existing deployments. | ||
|
|
||
| Changing the default value for the expected format of an existing config var in ``env.local`` |
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.
What do you mean by expected format 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.
Also, same note about using env.local vs "local environment file"
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.
Can this section be combined with the one above? Maybe I'm not understanding the difference between them but it seems like the advice for both scenarios is mostly the same.
| * Try to **avoid** this scenario as this is **backward incompatible** with all existing ``env.local`` on | ||
| all existing deployments. |
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.
| * Try to **avoid** this scenario as this is **backward incompatible** with all existing ``env.local`` on | |
| all existing deployments. | |
| * Try to **avoid** this scenario as this is **backward incompatible** without requiring existing deployments to manually update their local environment files. |
| * Try to **avoid** this scenario as this is **backward incompatible** with all existing ``env.local`` on | ||
| all existing deployments. | ||
|
|
||
| * Changing the format is potentially more disruptive than the default value. |
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.
Why? I'm not sure I understand
|
|
||
| to give time for all users to update all existing ``env.local`` on all existing deployments. | ||
|
|
||
| * **Document migration path** clearly in ``CHANGES.md``. If default value is changed, explain the impact |
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.
and in migration_guide.rst as well please
Overview
Added development conventions for config variables in
env.local, focusing on minimizing update friction and enhancing user experience.Related Issue / Discussion
CI Operations
birdhouse_daccs_configs_branch: master
birdhouse_skip_ci: false