SANDBOX-554 tests for setting ScheduledDeactivationTime on UserSignup

[sbryzak]

Tests for codeready-toolchain/host-operator#988

[sbryzak]

/retest

[sbryzak]

/retest

[rsoaresd]

Hello @sbryzak 👋 Just a minor suggestion:

[alexeykazakov]

Looks good. Apart from @rsoaresd's suggestion.

[MatousJobanek]

looks good, but it would be nice to update also the generic assertion function expecting the value to be always set for all provisioned UserSignup CRs.

toolchain-e2e/testsupport/user_assertions.go

Lines 64 to 106 in 4485a0f

	func VerifyUserRelatedResources(t *testing.T, awaitilities wait.Awaitilities, signup *toolchainv1alpha1.UserSignup, tierName string, userAccountOption UserAccountOption) (*toolchainv1alpha1.UserSignup, *toolchainv1alpha1.MasterUserRecord) {
	hostAwait := awaitilities.Host()
	// Get the latest signup version, wait for usersignup to have the approved label and wait for the complete status to
	// ensure the compliantusername is available
	userSignup, err := hostAwait.WaitForUserSignup(t, signup.Name,
	wait.UntilUserSignupHasStateLabel(toolchainv1alpha1.UserSignupStateLabelValueApproved),
	wait.ContainsCondition(wait.Complete()))
	require.NoError(t, err)
	userAccountStatusWaitCriterion := wait.UntilMasterUserRecordHasUserAccountStatusesInClusters()
	if userAccountOption.expectUserAccount {
	userAccountStatusWaitCriterion = wait.UntilMasterUserRecordHasAnyUserAccountStatus()
	if userAccountOption.targetCluster != nil {
	userAccountStatusWaitCriterion = wait.UntilMasterUserRecordHasUserAccountStatusesInClusters(userAccountOption.targetCluster.ClusterName)
	}
	}
	// First, wait for the MasterUserRecord to exist, no matter what status
	mur, err := hostAwait.WaitForMasterUserRecord(t, userSignup.Status.CompliantUsername,
	wait.UntilMasterUserRecordHasTierName(tierName),
	wait.UntilMasterUserRecordHasConditions(wait.Provisioned(), wait.ProvisionedNotificationCRCreated()),
	userAccountStatusWaitCriterion)
	require.NoError(t, err)
	// Verify last target cluster annotation is set
	lastCluster, foundLastCluster := userSignup.Annotations[toolchainv1alpha1.UserSignupLastTargetClusterAnnotationKey]
	require.True(t, foundLastCluster)
	// todo - change that as soon as we set the last-target-cluster annotation based on the "home" Space location
	// todo - and as soon as we drop the embedded UserAccounts from MUR
	require.Equal(t, mur.Spec.UserAccounts[0].TargetCluster, lastCluster)
	if userAccountOption.expectUserAccount {
	verifyUserAccount(t, awaitilities, userSignup, mur, userAccountOption)
	} else {
	for _, memberAwait := range awaitilities.AllMembers() {
	// let's verify that the UserAccounts from all members are gone
	err := memberAwait.WaitUntilUserDeleted(t, mur.Name)
	require.NoError(t, err)
	}
	}
	return userSignup, mur
	}

[MatousJobanek]

most likely some left-over from troubleshooting?

[sbryzak]

not quite left over, i'm actively trying to diagnose the cause of the current test failures.

[MatousJobanek]

Could we verify also the content of the timestamp, so we know that it's properly calculated and set?

[sbryzak]

Currently I'm only using this function to ensure the state of the UserSignup, i.e. the deactivation controller has run and set a value for the scheduled deactivation time property. In the test where I'm calling it I'm already checking the actual value is as expected.

[MatousJobanek]

I don't see that for all cases. Where do you verify the timestamp for this particular case?
https://github.com/sbryzak/toolchain-e2e/blob/1257d0941845405bbe0c584c05184d0795684640/test/e2e/user_management_test.go#L352-L355

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexeykazakov, sbryzak

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [alexeykazakov,sbryzak]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sbryzak]

@MatousJobanek i think that updating the generic VerifyUserRelatedResources function might be a bad idea, not all usersignups will have the scheduled deactivation time set, e.g. signups that are on an excluded email domain.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
8.6% Duplication on New Code

See analysis details on SonarCloud