Bamboo Build Failure Due to Platform Upgrade

@cintiadr created a ticket here

see PR

@cintiadr , now that that PR is merged , is there any more work to be done ,to have the qa-server up again ,apart from re-running the bamboo deployment plan ??

Ansible changes is not deployed automatically. I will roll it out now.

My question is: now that we changed the SDK to generate the correct data and fixed our servers, shouldn’t we delete the liquibase changes? As this is a problem with the original data.

1 Like

I think its still relevant for implementers who may run OpenMRS the Enteprise way , that is people who dont use the SDK or the standalone .

Well done @cintiadr. Our qa-server is now up again :grinning:

So if I understand what @burke is suggesting, it’s the same thing I am suggesting. That we don’t do the liquibase change, unless there’s any reason to say that this needs to be done for existing OpenMRS instances. I still don’t know if that’s the case, it seems a little bit odd.

1 Like

Thats true @cintiadr.

so @dkayiwa should we go ahead and revert that commit ??

@mozzy have you tested to confirm that a new platform install has an admin account with a username, when you do not have that commit?

Not yet ,i still have several issues to debug and resolve at the moment that i have discovered from the qa-server , after the platform upgrade,

may be @ruhanga can look at this for now ,since its his area :slightly_smiling_face:

@dkayiwa, @mozzy, the fix on the SDK looks good to me. I’ve been testing with fresh instances of the platform having the reverted change set, using the SDK and irrespective of the platform version, the admin user name is assigned to the systemID of admin. Looks like we are fine to revert the liquibase change set.

@ruhanga how about those who are not using the SDK?

Thanks for this @dkayiwa, I’m not sure if I clearly understood the motivation behind reverting the change set (keeping the original data consistent since there is a fix in the SDK). This will definitely affect those not using the SDK. So this now gets a little bit not clear to me whether to revert the liquibase change set or not. :confused:

I would keep the liquibase change-set for those not using the SDK in-order to be sure we don’t break things. I would make sure that the changeset has the required <preCondition/> to prevent overwriting changes from the SDK.

1 Like

Ideally That was my innitial thought , because the changeset has a pre-condition , if the user name “admin” exists it doesnt run , hence i also didnt see a necessary reason for the revert.

The whole cause of this thread was that , that change set couldnt run on our test enviroments , but we now corrected that. So i dont see the revert necesarry

Hi all,

For consistency across deployment environments in regards to the admin username being assigned to the systemId of admin, we will maintain the change set as discussed in today’s PM call. Unless there are any issues preventing the maintenance of the change set, perhaps an improved design approach that’d consider non SDK users, I’ll go ahead to release the platform with it not later than Tuesday 28th January.

1 Like

@dkayiwa @mozzy @cintiadr am creating an openmrs distro instance with Reference Application 2.11.0-SNAPSHOT but am still getting this issue Error executing SQL UPDATE `users` SET `username` = 'admin' WHERE system_id='admin': admin user account is locked . My openmrs sdk version is OpenMRS SDK 3.13.6. Here is the full error log https://pastebin.com/JZhAHbmE

@jecihjoy can you do a new sdk setup and share the log?

@dkayiwa I have run this command mvn org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:setup-sdk and created a new openmrs distro instance but still the same error

Can you share the full log from when you run the sdk setup?