Finding code snapshot of SQ 7.9.3 release

SonarQube
,
1

Hello,

We build from source code for our environment. Often the code release tags are missing from github making this hard. While 7.9.1LTS is tagged in github, 7.9.2 and 7.9.3 are not.

Can you please tag these releases in github - particularly 7.9.3 so that we can upgrade our platform.
We think the issues resolved https://jira.sonarsource.com/browse/SONAR-12449 and https://jira.sonarsource.com/browse/SONAR-12802 may be impacting us.

With many thanks and kind regards,

Will

2

Hello Will,

Sorry for that inconvenience, we’ve just pushed tags to mark appropriate SonarQube versions.

Jacek

2 Likes
3

Many thanks Jacek :slight_smile:

4

Hello @jacek.poreda,

Are you sure about these tags? Building and starting the tagged 7.9.3 using a copy of the 7.9.1 database and plugins led to this error:

ERROR web[][o.s.s.p.Platform] Web server startup failed: Database was upgraded to a more recent version of SonarQube. A backup must probably be restored or the DB settings are incorrect.

Digging a little deeper it seems the 7.9.1 db\version contains version up to v80.
However the tagged 7.9.3 contains only version up to v79.

Our schema_migrations table contains the last row of 95, with a max number in that column of 941, if that is relevant.

With thanks for your help.

David

5

Hello again,

I’ve double checked and it seems that everything is correct with migration numbers, below are links to the public repo of SQ pointing to lists of both versions.

List of migrations in 7.9.1

List of migrations in 7.9.3

As you can see there is no single v80 migration in a code. Moreover there weren’t any changes in db schema between 7.9.1 - 7.9.3.

Have you ever tried to upgrade your instance to 8.X ?

And could you execute this query on your database
select * from schema_migrations order by "version" desc limit 10;

or appropriate for your database and share results?

6

Hi @jacek.poreda,

Thanks for your response. The tagged version I downloaded last year looks different, with only DbVersion80.java, MakeOrganizationsGuardedNullable.java and package-info.java files in a v80 directory. This only looks like part of the v80 migration code that I can see in the master branch v80.

I must upgrade this database, so what are my options here? If I upgrade to an 8.X will it execute the missing migrations in the v80 directory? Preferably though I would like to migrate to 7.9.3 because some plugins may not support 8.X yet. Is there a way of doing that from here?

The result of the query:

> 95
> 941
> 940
> 939
> 938
> 937
> 936
> 935
> 934
> 933

Many thanks

Will

v80
v80851×144 5.16 KB

7

If it looks differently, it means it is not 7.9.X, it seems like your downloaded source code is something between 7.9 and 8.0, hard to say which one, because I don’t know which commit hash you have used to built it.

Also you can verify md5 hash of zip you have downloaded last year with the one from GH to be 100% sure.

Regarding the option you have:

  • move forward and upgrade to 8.1, 8.2 and then upgrade each time we release SQ until LTS, but as you mention you can suffer from plugins incompatibility
  • try to run valid 7.9.1 instance built from the tag 7.9.1 and see how it goes, although I do not recommend as it can be hard to debug it
8

Thanks @jacek.poreda,

The tagged source code is certainly different to the one I have - not sure how that happened but I am usually very careful to pull the correct tagged version.

I suspect I will have to take the first option and move from my 7.9.1+ version to the latest 8.1.

How resilient is the upgrade process likely to be in my case?

i.e. if I do this with my database only partially updated to v80 (my version seems to have only 1 of the 9 java migration files from that folder that I can see in 8.1), will it execute the missing eight java migrations that I can see in the v80 directory, or only execute those from the v81 migrations?

If not, is there a workaround such as copying the v80 files into the v81 folder beforehand or removing a row from the schema_migrations database to force it to reexecute v80 migrations (or both)?

Thanks again,

Will

9

You can start with 8.2 and it should execute 8.0, 8.1 and 8.2 migrations. More about upgrade process here.

Just a reminder for you to be careful and at first execute it on copy of database, so that you can restore your previous state just in case.

10

Thanks… I will try this and see how it goes.

11

This has worked successfully. Many thanks for your help :smile:

1 Like