feat(deadline): allow minor version upgrades in Repository construct #896
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.
Summary
Deadline 10.2.0.10 is released. The
Repository
construct has a check when upgrading Deadline versions to ensure the major and minor versions do not change. This prevents customers from upgrading to Deadline 10.2.This change removes the minor version part of the check. It also removes an unused and incorrect check in the example app's
bin/app.ts
file for the worker AMI map being empty. We have a default AMI set in the config anyway, so it's basically dead codeTesting
Repository
construct as expected:Repository cloud-init logs
Repository Installer logs
Note: The error message about creating an admin user in the database is a non-issue. This admin user for Deadline Secrets Management already exists from my 10.1.23.6 install.
RenderQueue logs
Note: The error message about granting access of master key (defaultKey) is a non-issue. The admin Deadline Secrets Management user already has access from my previous 10.1.23.6 install.
UBL logs
Worker logs
Worker cloud-init logs
Integration Test Results
All integration tests passed, expect for a couple failures in the Repository tests:
After investigating, I found that the failure is not due to a breaking change in RFDK, but rather a faulty test. I'm pretty sure this is just a race condition between the expected logs being published to the log stream and when the jest test queries the log stream. In the interest of time, I reran the tests locally by doing the same things the jest test does, just on my local machine:
DL-1-5 (source code)
DL-1-6 (source code)
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license