Author Archives: Niklas - Page 3

Git: “You can only push your own commits in this repository” – when there actually is a problem

I ran into this recently by creating a new Bitbucket repository when having a spelling error in my mail address in settings. I got this error:

remote: You can only push your own commits in this repository
remote: Commit 85eb7acbf42a14b9 was committed by Niklas Ottosson (username) <niklas@worldwideweeb.com>

In the commit 85eb7acbf42a14b9 (initial commit of the new repository) my mail was niklas@worldwideweeb.com when it should have been niklas@worldwideweb.com (only one ‘e’ in ‘web’)

To fix this we need to make sure we have the correct mail address in global settings:

git config --global user.email niklas@worldwideweb.com

and then reset the author of the initial commit

git commit --amend --reset-author --no-edit

This will now replace the previous author with me, and since I now have the correct spelling the commit will be “fixed”

Tested with Git 2.24.3

Gradle: Integration/GUI test setup example with Spring and Protractor

Setting upp integration tests that depends on background process can be a challenge in Gradle. Here is one solution that I have used:

gradle.build

apply plugin: 'java'

/**
* Handle of the background process (script scope)
*/
Process backendProcess

/**
* Task to start the Spring server
*/
task beforeE2eTests {
  ProcessBuilder builder
  builder = new ProcessBuilder('./gradlew bootRun'.split(' '))
  builder.redirectErrorStream(true)

  doLast {
    println "Starting backend"
    backendProcess = builder.start()

    InputStream sto = backendProcess.getInputStream()
    BufferedReader redr = new BufferedReader(new InputStreamReader(sto))

    /**
    * To prevent Gradle to go to next task before the server has started 
    * we add a loop that finds a specific log line. When that 
    * line appears we are good to go to next task
    */
    def line
    while ((line = redr.readLine()) != null) {
      println line
      if (line.contains("Started WebApplication")) {
        println "Backend is ready"
        break;
      }
    }
  }

  finalizedBy 'afterE2eTests'
}

/**
* Task to stop the Spring server
*/
task afterE2eTests {
  doLast {
    println "Stopping backend"
    backendProcess.destroy()
  }

  mustRunAfter 'testAngularE2e'
}

/**
* Task to start E2E tests
*/
task testAngularE2e(type: Exec) {
  mustRunAfter 'beforeE2eTests'

  /**
  * Run the Protractor tests
  */
  commandLine 'node_modules/.bin/protractor', 'e2e/protractor.conf.js'
}

/**
* Main testing task
*/
testAll {
  dependsOn beforeE2eTests, testAngularE2e
}

Tested on OSX 10.15.0 and Gradle 4.10.2

When you hit GRUB console on boot in an ASUS VivoMini UN45 with Ubuntu 18.04

I have an ASUS VivoMini that I run Ubuntu 18.04 on as a place for databases, Docker containers, and other stuff. Every now and then it boots me into GRUB console on reboots.

I’m here going to show how I use to solve is:

grub> set root=(hd0,2)
grub> linux /boot/vmlinuz-4.15.0-112-generic root=/dev/nvme0n1p2
grub> initrd /boot/initrd.img-4.15.0-112-generic
grub> boot

Explanation:
set root=(hd0,2) sets the disk an partition where the Linux installation is. Here is the first drive (hd0) and the second partition (2)
linux /boot/vmlinuz-4.15.0-112-generic root=/dev/nvme0n1p2 here I set the Linux kernel and the root path. It’s where I usually mess up. Most guides tell you to use /dev/sdaX (or sdbX or similar). The problem is that I use an internal Intel SSD witch identifies as nvme0 and not sda2, so when I try to use sda2 I get: “Gave up waiting for root file system /dev/sda2 does not exist. Dropping to shell”, but when I use nvme0n1p2 it works (nvme0n1p2 means first disk (n1) and second partition (p2))
initrd /boot/initrd.img-4.15.0-112-generic sets the initrd file. This has to be the same version as the vmlinux version
boot simply boots the system with the settings above. If all goes well we should reach the Ubuntu login screen (or console)

To make the changes permanent (until the next power outage or other misfortune) 

sudo update-grub

This will collect all data from the settings above and create a grub.cfg file. I needed sudo on my system, maybe you don’t. After we have created a new grub.cfg file we need to install it on the disk boot sector (not on a partition so no number for disk or partition here). For me, this was done by:

sudo grub-install /dev/nvme0

The system should now behave again 🙂

Tested on Ubuntu 18.04, GRUB 3.0, and Linux kernel 4.15.0-112