fix: improve name splitting in support bundle tests #278
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
example offender:
pod.aio-dataflow-upgrade-status-job-0.1.0-preview-rc9-4q4pg.aio-dataflow-upgrade-status-job.log
normal split will split by the ".", resulting in
['pod', 'aio-dataflow-upgrade-status-job-0', '1', '0-preview-rc9-4q4pg', 'aio-dataflow-upgrade-status-job', 'log']
which is bad
so we check if it is alpha numeric and try to join the name back together to get
['pod', 'aio-dataflow-upgrade-status-job-0.1.0-preview-rc9-4q4pg', 'aio-dataflow-upgrade-status-job', 'log']
Note this will break if there is a pod with a name with .'s that does not follow these rules. At this point there is no way to know what the expected pod name is without checking for the pod existence (and if it is a temporary/dynamic pod, it could be gone by then!!!).
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
Thank you for contributing to Azure IoT Operations tooling!
This checklist is used to make sure that common guidelines for a pull request are followed.
General Guidelines
Intent for Production
dev
ormain
are of production grade. Corollary to this, any merged contributions to these branches may be deployed in a public release at any given time. By checking this box, you agree and commit to the expected production quality of code.Basic expectations
pytest <project root> -vv
. Please provide evidence in the form of a screenshot showing a succesful run of tests locally OR a link to a test pipeline that has been run against the change-set..pylintrc
and.flake8
rules? Look at the CI scripts for example usage.Azure IoT Operations CLI maintainers reserve the right to enforce any of the outlined expectations.
A PR is considered ready for review when all basic expectations have been met (or do not apply).