Prevent accidentally switching a Sleeper instance between a local built version and a pre-published version
- Dominant language
- Java
- Stars
- 107
- Forks
- 29
- Avg merge
- 19h 46m
- Merged PRs (30d)
- 141
Description
### User Story
As a user of Sleeper, I want a CDK deployment of Sleeper to fail if it was deployed with a pre-published version and I'm running a locally built version, so that I don't accidentally replace an instance with one built in a different way.
### Description / Background
We'd like to ensure that if a Sleeper instance was deployed from a pre-published version, it should refuse being re-deployed from a locally built version, unless this is forced.
### Technical Notes / Implementation Details
The configuration for whether to deploy a locally built or pre-published version is in DeployConfiguration.
We can introduce a CDK-defined instance property to state whether the artefacts have been built locally or retrieved from a repository. We can set that based on a CDK context variable, which can be set by the deployNew.sh and deployExisting.sh scripts.
We can check this in two places:
- The deployExisting.sh script (DeployExistingInstance class)
- The uploadArtefacts.sh script (UploadArtefacts class)
#### Setting the CDK-defined instance property
We can create a CDK-defined property and set it in SleeperInstanceProps, similar to how `sleeper.cdk.app` is set.
This can be an enum property based on DockerImageLocation. We can move that enum to the core module.
#### Setting the CDK context variable
The deployNew.sh and deployExisting.sh scripts both set the CDK context variables against the CdkCommand that is passed to DeployConfiguration in a DeployInstanceRequest.
Both of these already read the deployment configuration with `DeployConfiguration.fromScriptsDirectory`, but this is currently done inside a factory method for DeployInstance. We may need to adjust that wiring.
#### Checking the instance property matches
The deployExisting.sh and uploadArtefacts.sh scripts both load DeployConfiguration indirectly. We may need to adjust that wiring.
In uploadArtefacts.sh we'll only be able to do this check if the instance properties are loaded.
The check can be an equality check on a DockerImageLocation.
Both of these scripts will need new options to force deployment even if the artefacts source does not match.
Contributor guide
Research direction
Start with DeployConfiguration, SleeperInstanceProps, and the DeployInstanceRequest wiring, then trace deployNew.sh and deployExisting.sh through DeployExistingInstance. Review uploadArtefacts.sh and UploadArtefacts to see how instance properties are loaded. Done means deployments reject mismatched local and pre-published artefact sources, while both scripts provide a force option to bypass the check.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, shell
- Domain
- cloud, devops, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100