How do I get the Flyway version number of a database - jenkins

I want to pull out the pre-deployment Flyway version number of my production database so I can use this in my continuous deployment pipeline (Jenkins) in case I do a rollback later.
How can I achieve this?
One option would be to query the flyway history table, but I can't work out a fail-safe way of achieving this.

I have fashioned an answer, although it feels like a big of a hack. I run --dryRunOutput in migrate as a means to get flyway to output the version number to the screen, as info doesn't do this for some reason.
I read the output into a file (because DOS makes it hard to pipe or pass into a variable) then isolate the output line starting with "Current". I then pick the second token using : as my delimeter. There's probably an easier way, and I wish I could use flyway info instead of migrate as my method feels hacky, but at least it works for now.
flyway -dryRunOutput=test.sql migrate | FIND "Current" >currentversion.txt
for /f "delims=" %%x in (currentversion.txt) do set CURRENTVERSIONLINE=%%x
for /f "tokens=1,2 delims=:" %%a in ("%CURRENTVERSIONLINE%") do set CURRENTVERSION=%%b
echo Version : %CURRENTVERSION%

The following one-liner does what you want:
flyway info | grep Success | tail -1 | cut -f3 "-d|" | xargs

Related

GNU parallel: deleting line from joblog breaks parallel updating it

If you run GNU parallel with --joblog path/to/logfile and then delete a line from said logfile while parallel is running, GNU parallel is no longer able to append future completed jobs to it.
Execute this MWE:
#!/usr/bin/bash
parallel -j1 -n0 --joblog log sleep 1 ::: $(seq 10) &
sleep 5 && sed -i '$ d' log
If you tail -f log prior to execution, you can see that parallel keeps writing to this file. However, if you cat log after 10 seconds, you will see that nothing was written to the actual file now on disk after the third entry or so.
What's the reason behind this? Is there a way to delete something from the file and have GNU parallel be able to still write to it?
Some background as to why this happened:
Using GNU parallel, I started a few jobs on remote machines with --sshloginfile. I then needed to pkill a few jobs on one of the machines because a colleague needed to use it (and I subsequently removed the machine from the sshloginfile so that parallel wouldn't reuse it for new runs). If you pkill those processes started on the remote machine, they get an Exitval of 0 (it looks like they finished without issues; you can't tell that they were killed). I wanted to remove them immediately from the joblog so that when I restart parallel --resume later, parallel can have a look at the joblog and determine what's missing.
Turns out, this was a bad idea, as now my joblog is useless.
While #MarkSetchell is absolutely right in his comment, root problem here is due to man sed lying:
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if SUFFIX supplied)
sed -i does not edit files in place.
What it does is to make a temporary file in the same dir, copy the input file to the temporary file while doing the editing, and finally renaming the temporary file to the input file's name. Similar to this:
sed '$ d' log > sedXxO11P
mv sedXxO11P log
It is clear that the original log and sedXxO11P have different inodes - let us call them ino1 and ino2. GNU Parallel has ino1 open and really does not know about the existence of ino2. GNU Parallel will happily append to ino1 completely unaware that when it closes the file, the file will vanish because it has already been unlinked.
So you need to change the content of the file without changing the inode:
#!/usr/bin/bash
seq 10 | parallel -j1 -n0 --joblog log sleep 1 &
sleep 5
# Obvious race condition here:
# Anything appended to log before sed is done is lost.
# This can be avoided by suspending parallel while running this
tmp=$RANDOM$$
cp log $tmp
(rm $tmp; sed '$ d' >log) < $tmp
wait
cat log
This works right now. But do not expect this to be a supported feature - ever.

Reset Plastic SCM workspace

Using the command line how can I reset my workspace so that it becomes an exact replica of server version of changeset I'm on? More specifically, how to get rid of all pending changes, all added and removed files, and everything not yet committed to Plastic? Note that cm unco --all does not remove "private" files.
I'm currently using an ugly hack:
FOR /f "tokens=*" %%a in ('cm status --short --private') DO DEL /F /Q "%%a"
cm unco --all --dependencies
Which works okay, however a recent change to cm status causes it to print an extra Finding changed files took too long. Perf tips: https://www.plasticscm.com/download/help/statusperfhintschanged at the end, which throws off the for loop. I haven't found a way to suppress the warning message.

Change database.location from command line

Is there a way to specify a Neo4j database location at command invocation time, instead of via a file? So instead of putting the following in neo4j-server.properties:
org.neo4j.server.database.location=/path/to/db
Something like:
neo4j --db=/path/to/db
I'm still on Neo4j 2.1.6 but advice on any version is better than nothing.
My particular use case at this time is, my regular DB is having problems and I want to quickly spin up a blank database just to narrow down the problem to binaries or data (yes I've checked the log files!).
You could use sed to edit neo4j-server.properties before starting neo4j. Something like:
sed -i.bak s/org.neo4j.server.database.location=databases/org.neo4j.server.database.location=newdatabase/g neo4j-community-2.1.6/conf/neo4j-server.properties
You could create a simple script that takes the path as a param. So something like:
./start-neo.sh mytestdb where start-neo.sh is:
sed -i.bak s/org.neo4j.server.database.location=databases/$1/g neo4j-community-2.1.6/conf/neo4j-server.properties
neo4j-community-2.1.6/bin/neo4j start
will set org.neo4j.server.database.location=mytestdb and then start neo4j.

Register for messages from collabd like XCSBuildService to receive Xcode Bots integration number

During an Xcode Bots build each run gets an integration number assigned. This number does not show in the build logs but would be convenient to create http links back to the individual Xcode Bots build in an CI environment or enterprise app store.
In the /Library/Server/Xcode/Logs/xcsbuildd.log I found that XCSBuildService gets a message/event from collabd with a structure that contains the integration number.
Is there a way to register to the same event in an own (OSX) program and receive this message/event?
The only ugly way I found so far to get the Xcode Bots integration number was by parsing the xcsbuildd.log file with the drawback that I can't be sure that the latest integration number corresponds with my current build when several builds are executing in parallel.
This log file is also located in an read protected folder/file so that I have to either change the permissions (ugh!) or use sudo (I don't really want to do that)!?
Example:
sudo grep -r "integration =" /Library/Server/Xcode/Logs/xcsbuildd.log | tail -1 | cut -d'=' -f 2| cut -d';' -f 1 |tr -d '\040\011\012\015'
Gives me the latest integration number stripped from whitespace ...
Edit:
Just found out that if you actually include the following script in your scheme as Build-post-action it will create a file (e.g. /Library/Server/Xcode/Data/BotRuns/Cache/22016b1e-2f91-4757-b3b8-322233e87587/source/integration_number.txt) with the integration number without requiring sudo. Xcode Bots seems to serialize the different builds so that they are not executed in parallel and so the created integration number in the file could be used.
grep -r "integration =" /Library/Server/Xcode/Logs/xcsbuildd.log | tail -1 | cut -d'=' -f 2| cut -d';' -f 1 |tr -d '\040\011\012\015' > ${PROJECT_DIR}/integration_number.txt
For specifically the case of getting the integration build number, I've added a simple answer here.
To repeat myself (and keep this from being down voted as a 1-line answer):
I implemented this using a Shell Script Build Phase in my Xcode project. In my case, I used the integration number to set the internal version of my built product. My script looks like this:
if [ "the$XCS_INTEGRATION_NUMBER" == "the" ]; then
echo "Not an integration build…"
xcrun agvtool new-version "10.13"
else
echo "Setting integration build number: $XCS_INTEGRATION_NUMBER"
xcrun agvtool new-version "$XCS_INTEGRATION_NUMBER"
fi
Note that XCS_INTEGRATION_NUMBER exists by default in the Xcode Server build environment. If you want to simulate an integration build (for the purposes of this script), you can simply add it to your build settings as a custom variable.

grep command that works on Ubuntu, but not on Fedora

I clean hacked Wordpress installations for clients on a regular basis, and I have a set of scripts that I have written to help me track down where the sites are hacked. One code snippet that I use on a regular basis worked fine on Ubuntu, but since switching to Fedora on Friday has quite behaving as expected. The command is this:
grep -Iri --exclude "*.js" "eval\s*(" * | grep -rivf ~/safeevals.txt >../foundevals.txt;
What it is supposed to happen (and did happen when I was using Ubuntu): grep through all non-binary files, excluding Javascript includes, for all occurances of the eval() function, then perform a negative match on a line by line basis against all known occurances of the eval() function in a vanilla installation of Wordpress (the patterns of which are in ~/safeevals.txt).
What is actually happening: The first part is working fine, as I ran it separately and it did find all instances of eval() in the installation. However, instead of greping through those results, after the pipe is it re-grepping through all of the files, returning a negative match of ~/safeevals.txt (ie. pretty much every line of every file in the installation).
Any idea why the second grep isn't acting on the piped data, or what I need to do to fix it? Thanks.
-Michael
Just tested on my Debian box: apparently, grep -r likes to assume a default argument of .. I am really wondering if that behaviour is valid. Anyway, I guess dropping the -r option from the second grep command will fix it.
Edit: rgrep defaulting to $PWD seems to be a recent change in grep, see this discussion on unix.stackexchange and the link there to the commit in the upstream grep code repository.

Resources