Skip to content

6593 improve usability of deploy new script#7606

Open
ca61688 wants to merge 49 commits into
developfrom
6593-improve-usability-of-deploy-new-script
Open

6593 improve usability of deploy new script#7606
ca61688 wants to merge 49 commits into
developfrom
6593-improve-usability-of-deploy-new-script

Conversation

@ca61688

@ca61688 ca61688 commented Jul 6, 2026

Copy link
Copy Markdown
Collaborator

Make sure you have checked all steps below.

Issue

  • My PR fully resolves the following issues. I've referenced an issue in the PR title, for example "Issue 1234 - My
    Feature". Note that before an issue is finished, you can still make a pull request by raising a separate issue
    for your progress.

Tests

  • My PR adds the following tests based on our test strategy OR does not need testing for this extremely good reason:
    • Manual testing including quick system test suite run

Documentation

  • In case of new functionality, my PR adds documentation that describes how to use it, or I have linked to a
    separate issue for that below.
  • If I have added new Java code, I have added Javadoc that explains it following our conventions and style.
  • If I have added or removed any dependencies from the project, I have updated the NOTICES file.

@ca61688
ca61688 force-pushed the 6593-improve-usability-of-deploy-new-script branch from 227e99c to a1411a6 Compare July 7, 2026 08:03
@ca61688
ca61688 marked this pull request as ready for review July 14, 2026 15:38
@ca61688 ca61688 added the needs-reviewer Pull requests that need a reviewer to be assigned label Jul 14, 2026

@patchwork01 patchwork01 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what to do about it yet but I'm struggling to review this. We'd better talk about what we can do. I remember it was a pain to work with last time I tried to refactor it as well.

}

public void update() throws IOException, InterruptedException {
SleeperInstanceConfiguration deployConfig = SleeperInstanceConfiguration.builder().instanceProperties(properties).tableProperties(tablePropertiesList).build();

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This SleeperInstanceConfiguration is built twice, here and in the DeployInstanceRequest. Maybe it would be better to reference the instance and table properties fields directly when we write them to the local directory?

deployConfig.getInstanceProperties(),
deployConfig.getTableProperties().stream());
} catch (IOException e) {
throw new UncheckedIOException(e);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method declares throws IOException, so it looks like the try/catch isn't needed.

private final CdkCommand cdkCommand;
private final SleeperInternalCdkApp cdkApp;
private Path propertiesFile;
private Path configDir;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These fields can be declared final. See our coding conventions: https://github.com/gchq/sleeper/blob/develop/docs/development/conventions.md#use-of-final

cdkCommand = Objects.requireNonNull(builder.cdkCommand, "cdkCommand must not be null");
cdkApp = Objects.requireNonNull(builder.cdkApp, "cdkApp must not be null");
propertiesFile = builder.propertiesFile;
configDir = builder.configDir;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should validate that one or the other of these fields are set here?


public Path getConfigDir() {
return configDir;
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We try to avoid needing null checks on values retrieved from a getter. See our coding conventions: https://github.com/gchq/sleeper/blob/develop/docs/development/conventions.md#null-handling

Looking at how these are used in DeployInstance, I don't think think the new fields are needed at all. We can set this on the CdkCommand instead?

instanceProperties.set(SUBNETS, "someSubnets");
assertThat(instanceProperties)
.isEqualTo(SleeperInstanceConfiguration.fromLocalConfiguration(
instancePropertiesFile).getInstanceProperties());

@patchwork01 patchwork01 Jul 15, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is the correct behaviour? We don't want to edit the user's configuration file, so we need to pass these as CDK context variables. I don't understand what's doing this in the production code, it looks like the code that was writing the file before is faked for the test.

void shouldDeployNewInstanceWhenUsingInstanceProperties() throws Exception {
//When
deployNewInstance("scriptsDir", "someInstance", "someVpc", "someSubnets", "--instance-properties",
instancePropertiesFile.toString());

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please can we avoid passing the scripts directory explicitly as part of the arguments? The user won't set that.

It also looks like this is not the correct value for that? Why isn't that causing a problem?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've made deployNewInstance add "scriptsDir" itself so the tests dont pass it in. The scripts directory is only used in the main method when creating a new DeployInstance which my tests don't interact with as I'm passing in the way to record the requests instead of actually deploying anything.

ClientUtils.clearDirectory(configDir);
SaveLocalProperties.saveToDirectory(configDir,
deployConfig.getInstanceProperties(),
deployConfig.getTableProperties().stream());

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is duplicated in a couple of places, can we put it in SaveLocalProperties?

deployPaused = builder.deployPaused;
public DeployNewInstance(InstanceDeployer deployInstance,
StoreFactory storeFactory,
SleeperInstanceConfiguration deployInstanceConfiguration,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm struggling to understand how this is passed around now, particularly as the path it comes from is passed as separate parameters alongside it.

void setUp() throws IOException {
createTempDirectory(tempDir, null);
instancePropertiesFile = tempDir.resolve("instance.properties");
Files.writeString(instancePropertiesFile, instanceProperties.saveAsString());

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is generating an InstanceProperties object with InstancePropertiesTestHelper, and that simulates a pre-deployed instance. It's then writing it to a local file and treating it as a user's configuration file. I don't think it makes sense to treat one as the other, and I'm struggling to follow how these values are used.

@patchwork01 patchwork01 removed the needs-reviewer Pull requests that need a reviewer to be assigned label Jul 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Improve usability of deployNew.sh

2 participants