I have version v1, v2 in schema_version table.
I want to add version v1.1 in between.
How can i do it using cmd's with out manually dropping v2 and running flyway migrate once again?
Run with outOfOrder turned on; see the migrate docs.
Option: outOfOrder
Required: No
Default: false
Description: Allows migrations to be run "out of order".
If you already have versions 1 and 3 applied, and now a version 2 is found, it will be applied too instead of being ignored.
If you're running via the command line then do the following:
Add new migration as V1.1__description.sql or similar
Run flyway again with -outOfOrder true
Related
Running the .NET Core Pack task, how do I get the outputted NuGet package version to auto-increment itself?
So, for example, if my current version is 1.0.0, then the next time I call the Pack task, I would like to see 1.0.1.
I'm using environment build variables with Build.BuildNumber and getting outputs at the moment of e.g. 20180913-.2.0, etc. I would like to establish to a more traditional versioning system.
From the docs, the variable Rev:.r is the daily build revision count. The accepted "solution" would lead to one day finishing having a version of 1.0.12, then the next day it will be 1.0.1.
If you want a simple incremental and unique semver, use 1.0.$(BuildID).
$(BuildID) is an internal immutable counter for your builds, and thus far cleaner than $(BuildNumber).
BuildID will always be incrementing - no reset.
Thus after a minor bump, you'd end up having say 1.2.123 becoming 1.3.124.
If you want to perform this task well, this can be done using npm version or similar, such as pubspec_version for Dart or Flutter builds.
- script: npm version $RELEASE_TYPE
where $RELEASE_TYPE is a variable you can set based on build (ie: CI, PR etc), having a value of major, minor, patch, prerelease etc.
- script: npm version $RELEASE_TYPE
condition: startsWith(variables['build.sourceBranch'], 'refs/head/release/')
env:
releaseType: minor
Update: Bump Repo Version and Use In Build (using npm)
To have the repo version update, I ended up including npm version as a DevDependency, with it's precommit hook to bump the project version on any commit.
This technique can be applied to other project types, placing them in a subfolder - although can lead to complications with server OS requirements.
To use this version in your build, add this bash script task, which gets and exports the version as a task variable:
v=`node -p "const p = require('./package.json'); p.version;"`
echo "##vso[task.setvariable variable=packageVersion]$v"
.Net Core Task only version
Unfortunately, no repo-bump.
Workaround 1:
jobs:
- job: versionJob #reads version number from the source file
steps:
- powershell: |
$fv = Get-Content versionFile
Write-Host ("##vso[task.setvariable variable=versionFromFile;isOutput=true]$fv")
displayName: 'version from file'
name: setVersionStep
- job: buildJob # consumes version number, calculates incremental number and set version using assemblyinfo.cs
dependsOn: versionJob
variables:
versionFromFile: $[ dependencies.versionJob.outputs['setVersionStep.versionFromFile'] ] # please note that spaces required between $[ and dependencies
buildIncrementalNumber: $[ counter(dependencies.versionJob.outputs['setVersionStep.versionFromFile'],1) ] #can't use $versionFromFile here
steps:
- powershell: |
Write-Host ($env:versionFromFile)
Write-Host ($env:versionFromFile + '.' + $env:buildIncrementalNumber)
displayName: 'version from file output'
Workaround 2:
This post describes a couple of others, using version-prefix and automatically applying the BuildNumber as a version-suffix.
I may have figured it out. For anyone tearing their hair out, try this:
Pack Task:
Automatic Package Versioning: Use an environment variable
Environment variable: Build.BuildNumber
Then, up in the top menu where you have Tasks, Variables, Triggers, Options, click Options and set:
Build number format: 1.0$(Rev:.r)
Save and queue. This will produce e.g. 1.0.1.
(Please Correct me if I am wrong, or if this does not work long-term.)
If you're just looking to bump the major, minor or revision version number, using counter operator in a variable is a simple and elegant approach. It will automatically add one to the current value.
Here's what I use:
variables:
major: '1'
minor: '0'
revision: $[counter(variables['minor'], 1)] #this will get reset when minor gets bumped. The number after Counter is the seed number (in my case, I started at 1).
app_version: '$(major).$(minor).$(revision)'
If you would like to see a real-world 4-job pipeline that uses this, I have one here https://github.com/LanceMcCarthy/DevReachCompanion/blob/master/azure-pipelines.yml
For me it's enough to set Build number format on Options tab to
$(date:yyyy).$(date:MMdd)$(rev:.r)
and add next build argument:
/p:Version=1.$(Build.BuildNumber) /p:AssemblyVersion=1.$(Build.BuildNumber)
In this case we manage major version manually, but minor version and build number will be set automatically. Easy to understand what version you have deployed.
I am using the ado pipeline and a yaml build. What I've done is utilized the pipeline variables, a counter function, and an inline powershell function to create the version number. It auto-increments and has made the entire build process nice.
Another SO Post about something similar
I have a setup in which migrations from previous scripts were removed.
The flyway configuration specifies that ignoreMissingMigrations is true.
However, Flyway fails with the following error
Validate failed: Detected applied migration not resolved locally: version_x
where version_x is the first version that was removed after baseline.
Why do I get this error although ignoreMissingMigrations is true ?
Note: Flyway version: 4.2.0
The problem comes from a special setup that Flyway is unable to handle correctly.
We have no newer applied migration, thus Flyway see this migration as a future migration instead of a missing migration. Thus the solution is to set ignoreFutureMigrations to true in addition to ignoreMissingMigrations.
Can Flyway be used to mix creation and migration scripts so that:
new installations run a schema creation script
existing installations run migration scripts, and never see the creation scripts of subsequent versions
?
E.g. given:
db/create/V1/V1__schema.sql
db/create/V2/V2__schema.sql
db/create/V3/V3__schema.sql
db/migration/V1/V1.1__migrateA.sql
db/migration/V2/V2.1__migrateB.sql
db/migration/V2/V2.2__migrateC.sql
An existing V1 installation would run the following to get to V3:
db/migration/V1/V1.1__migrateA.sql
db/migration/V2/V2.1__migrateB.sql
db/migration/V2/V2.2__migrateC.sql
It would never run the following, as these represent schema-only SQL produced by mysqldump:
db/create/V2/V2__schema.sql
db/create/V3/V3__schema.sql
A new V3 installation would run:
db/create/V3/V3__schema.sql
The above conflicts with the approach recommended by Upgrade scenario when using Flyway but is required as data is populated independently of the migration.
It looks like it should be possible to use flyway.locations to support this, but installations would always need to include the path to their creation script so that Flyway can see it.
The alternative appears to be to run the creation scripts outside of Flyway and set a baseline, but it would be nice if Flyway could manage everything.
In the end, I developed a tool to do this.
The tool has the latest schema in:
db/schema/schema.sql
and the migration scripts in:
db/migration/<version>/<version>.<sequence>__<JIRA issue>.sql
e.g.:
db/migration/V1/V1.1__JIRA-15.sql
db/migration/V2/V2.1__JIRA-12.sql
db/migration/V2/V2.2__JIRA-22.sql
db/migration/V3/V3.0__JIRA-34.sql
If the database has no tables, schema.sql is executed, and then flyway is baselined with the most recent version, as reported by Flyway's
MigrationInfoService.pending() method.
i.e. the last MigrationInfo element returned by pending() determines the version to pass to Flyway.setBaselineVersion() before invoking Flway.baseline()
e.g:
DbSupport support = DbSupportFactory.createDbSupport(connection, true);
Schema schema = support.getOriginalSchema();
if (schema.allTables().length == 0) {
Resource resource = new ClassPathResource("db/schema/schema.sql", getClass().getClassLoader());
SqlScript script = new SqlScript(resource.loadAsString("UTF-8"), support);
script.execute(support.getJdbcTemplate());
MigrationInfo[] pending = flyway.info().pending();
MigrationInfo version = pending.length > 0 ? pending[pending.length - 1] : null;
if (version != null) {
flyway.setBaselineVersion(version.getVersion());
flyway.setBaselineDescription(version.getDecription());
flyway.baseline();
}
}
This ensures that none of the migration scripts are invoked for newly created databases, but does mean that schema.sql must already contain all of the changes.
If the database has tables, but no Flyway information, it is baselined according to the detected schema version.
I get this error when I create a new module:
"Please upgrade your database: Run "bin/magento setup:upgrade" from the Magento root directory.
The following modules are outdated:
Sangeeta_Octan data: current version - none, required version - 0.0.1";i:1;s:1781:"#0
I searched on google and found no solution other than reinstalling Magento. Such as:
version has been changed from "2.0.0.0" to "2.0.0" during development,
so update tool can't recognize that "2.0.0.0" <= "2.0.0". Please,
re-install your application from scratch to get latest version. `
Do I have any options apart from reinstalling?
Change the setup_version of your module (Sangeeta_Octan) in
app/code/Sangeeta/Octan/etc/module.xml. Try a different version
name like setup_version="2.0.1" or setup_version="3.0.0"
Run bin/magento setup:upgrade
If that doesn't work, disable your module by changing your module name in app/etc/config.phpfrom Sangeeta_Octan => 1 to Sangeeta_Octan => 0. Then run bin/magento setup:upgrade
I hope below solution also solve your problem.
https://magento.stackexchange.com/questions/112293/mysql-error-and-possible-duplicates-running-bin-magento-setupupgrade-after-rena/112299#112299
in mysql find the table setup_module It will have 3 fields. Find the NULL values in data_version & have them match the schema_version
As an alternative, you can access your magento database and look at the table setup_module
You will see a list of all installed modules and you can manually set the schema/data version numbers here.
Delete the offending rows from the setup_module table (if they are there) and run the command bin/magento setup:upgrade from your Magento 2 root directory.
This is happens because of something wrong while running "bin/magento setup:upgrade" and the data_version in Module versions registry is null. It is loaded from DB, We can just proceed by manually changing it in db.
Go db via php myadmin and check "setup_module" table, the
data_version which are mentioned "null".
Login to Mysql database => then update table setup_module of the "data_version" column same as "schema_version"
I'm using flyway with gradle, I've run one of the migrations manually inside the database console, I want to run flyway, but tell it to ignore one specific migration version in between all the others.
Can this be done?
You would have to hack it a bit to get it to work, so I don't recommend this approach, but it would work in a pinch.
I've only tested this with Maven, but I'm pretty sure it'd work with Gradle too.
Migrate up until the version before the one you applied manually
# Assuming you applied 01.002 manually
$ mvn flyway:migrate -Dflyway.target=01.001
Insert a row for the script you applied
-- Make sure these vals closely replicate those from other rows
insert into schema_version( installed_rank, version, description, type, script, checksum, installed_by, installed_on, execution_time, success)
values ( 2, '01.002', 'static_data', 'SQL', 'V01/V01.002__static_data.sql', null, 'username', current_timestamp, 0, true );
Repair the schema_version checksum
$ mvn flyway:repair
Apply the other migrations
$ mvn flyway:migrate -Dflyway.validateOnMigrate=false -Dflyway.outOfOrder=true
The two -D properties there may not be necessary, depending on whether you got the insert correct or not. Flyway may disagree with your script description, for example, even if the checksum is now correct.
Not Recommended, but if you still want to:
Run flywayMigrate, let the migration fail.
Manually, update the flyway meta table (success column) for that specific version of migration.
Run flywayMigrate again.
Done, flyway will now start with the next version of migration.
As of version 7, you can add it directly to your Maven or Grade file
Gradle - Skip
flyway {
skipExecutingMigrations = true
}
Maven - Skip
<configuration>
<skipExecutingMigrations>true</skipExecutingMigrations>
</configuration>
Documentation Reference Skip
Gradle - Cherry Pick
flyway {
cherryPick = '2.0'
}
Maven - Cherry Pick
<configuration>
<cherryPick>2.0</cherryPick>
</configuration>
Documentation Reference Cherry Pick