AWS CodeBuild + Bitbucket – Teams = Epic Fail

Main menu:

Topics

Recent Posts

Feeds

RSS Feed RSS - Posts

August 2017
M T W T F S S
« Jul    
 123456
78910111213
14151617181920
21222324252627
28293031  

Past Posts

Java/Java EE

JDBC

Other

AWS CodeBuild + Bitbucket – Teams = Epic Fail

August 17th, 2017 by Scott Selikoff


Updated 8/19/2017: Amazon has now updated AWS CodeBuild service to support Teams! In other words, in the 2 days since I posted this issue, it has now been fixed. Hooray! I now see my team projects in the list of repositories after linking my account. One minor nitpick though… They sort the list of repositories in the drop-down chronologically, not alphabetically. Since I have hundreds of repositories, that means in order to find a particular one I have to remember the order it was created. Hope they fix this (minor) issue too!


As a user of both Bitbucket and AWS, I was recently excited to hear Amazon had announced integration with both AWS CloudBuild and Atlassian Bitbucket. For those unfamiliar with these two products, AWS CloudBuild is part of Amazon’s suite of code automation CI/CD toolset. This service, along with the full suite, provides the ability to automate software build creation, testing, and deployment. Atlassian Bitbucket, on the other hand, is a large source code repository provider. The AWS announcement means that you can now build projects in AWS using Bitbucket repositories as the source.


Or that’s what it was supposed to mean… Apparently, no one told AWS that most professional software development companies use Bitbucket Teams to manage projects. The new AWS integration is accomplished using an OAuth authenticated sign-in from within the AWS CodeBuild project creation wizard. Unfortunately, after logging in it only allows two types of repositories to be selected: public repositories and those in your *personal* account. Most people using Bitbucket professional use teams and do not store the repositories in their personal account. The result is that no repositories are available for integration.

In other words… it’s broken. One solution would be to authenticate with the team login but Atlassian disabled the ability to login with the team account years ago. Now, Amazon only announced this feature recently, so it is possible they will get around to fixing it but in the short-term it is quite disappointing. While there are other ways to integrate AWS CodeDeploy and Bitbucket, I was looking for an all-in-one solution. In fact, when I recently tried Atlassian’s plugin to integrate one of my repositories into AWS CodeBuild, the web page just froze. Oh well, hopefully Amazon will fix this oversight soon!

By the way, you might ask, “Why I don’t just move my source code repository into AWS CodeCommit?” The answer is simple logistics. If I have hundreds of projects used by hundreds of developers, migrating them to a new repository is not easy/fun. The advantage of having this integration working is that it provides a nice, fluid transition toward migrating to AWS builds, without the commitment of actually transferring any repositories.

junit 5 and intellij

August 13th, 2017 by Jeanne Boyarsky

I use Eclipse at home for development. And mostly Maven (except for two projects that use Ant because some of the people working on them have less reliable internet connections).

After preparing to run JUnit 5 with Eclipse and Maven, I wanted to check the impact on IntelliJ. It’s been a long time since I’ve tried using IntelliJ. The internet says it supports JUnit 5 so I wanted to try it to confirm. I need to know this:

  1. So I know what IDEs people can use at my JavaOne JUnit 5 hands on lab
  2. So I know whether upgrading the CodeRanch JForum fork to JUnit 5 will be a problem for the developers using IntelliJ

Installing IntelliJ

  1. Download Mac version of free community edition from JetBrains
  2. Drag .dmg folder to Applications folder
  3. I chose not import settings. I don’t even remember the last time I ran IntelliJ on my Mac so those settings aren’t likely to be useful.
  4. After accepting the privacy policy, IntelliJ opens and I chose all the defaults.

Running the project

To run the project I migrated, I chose:

  • Check out from version control > git
  • https://github.com/boyarsky/oracle-java-cert-objectives-history.git and clone
  • IntelliJ asked if wanted to create a project based on the pom and I said yes
  • Choose command 1 for project view
  • Tried to open a Java class and got prompted to configure the SDK. I chose the latest Java 8 on my machine. No need to use Java 9 for what I’m doing. /Library/Java/JavaVirtualMachines/jdk1.8.0_xxx.jdk/Contents/Home
  • Build using build pulldown
  • Run using run pulldown

The result

IntelliJ was able to recognize the JUnit 5 annotations/methods and run them. It’s a bit ahead of Eclipse in this space so JUnit 5 won’t be a problem if they are using the latest version of IntelliJ.

upgrading to junit 5 parameterized tests for the first time

August 13th, 2017 by Jeanne Boyarsky

I’ve been playing with JUnit 5 for a while. Migrating existing project is something else so I decided to try with my small project cert objectives checker. This project does run on Jenkins so is a good test because it isn’t just on my machine. First I set up Eclipse and Maven to work with JUnit 5.

Switch to Jupiter APIs

Since I only had 5 classes, I updated by hand. For each class:

  1. Changed imports to
    import static org.junit.jupiter.api.Assertions.*;
    import static org.hamcrest.MatcherAssert.assertThat;
    import org.junit.jupiter.api.*;

    (The hamcrest one is so I can keep using assertThat)

  2. Changed assertEquals/assertTrue/etc calls to have String message as last parameter instead of first.
  3. Changed @Before to @BeforeEach
  4. Got distracted and updated tests to Java 8 syntax (nothing to do with JUnit)
  5. Changed to use new ParameterizedTest syntax. More on this…

Parameterized tests

Interestingly Eclipse knows about the new Parameterized Tests dependency natively. But if you use Maven, you need to add a dependency:

<dependency>
  <groupId>org.junit.jupiter</groupId>
  <artifactId>junit-jupiter-params</artifactId>
  <version>5.0.0-RC2</version>
</dependency>

Now let’s compare the before and after. I’ve omitted parts that are the same in both (aka the detailed logic of my test). Not that it is secret of anything. (After all the project is public on github.) But it makes it easier to compare the differences with less code.

JUnit 4 version

import static org.junit.Assert.*;

import java.io.*;
import java.net.*;
import java.nio.file.*;
import java.util.*;

import javax.xml.parsers.*;

import org.junit.*;
import org.junit.runner.*;
import org.junit.runners.*;
import org.junit.runners.Parameterized.Parameters;
import org.w3c.dom.*;

@RunWith(Parameterized.class)
public class CheckForChangesIT {

  @Parameters
  public static List<CertsToCheckEnum[]> suite() {
    List<CertsToCheckEnum[]> result = new ArrayList<>();
    for (CertsToCheckEnum element : CertsToCheckEnum.values()) {
       result.add(new CertsToCheckEnum[] { element });
    }
    return result;
  }
  // ----------------------------------------------------
  private CertsToCheckEnum certToCheck;
  private InputStream stream;
  private Document doc;

  public CheckForChangesIT(CertsToCheckEnum certToCheck) {
    this.certToCheck = certToCheck;
  }
  // ----------------------------------------------------
  @Before
  public void connect() throws Exception {
    String url = XML_URL + certToCheck.getExamNumber();
    stream = new URL(url).openStream();
  }
  @After
  public void close() {
    if (stream != null) {
      try {
        stream.close();
      } catch (Exception e) {
        // ignore
      }
    }
  }
  // ----------------------------------------------------
  @Test
  public void upToDate() throws Exception {
    parseDocument();
    String currentData = convertToString();
    assertSameAsExisting(currentData);
  }

JUnit 5 version

import static org.junit.jupiter.api.Assertions.*;

import java.io.*;
import java.net.*;
import java.nio.file.*;

import javax.xml.parsers.*;

import org.junit.jupiter.params.*;
import org.junit.jupiter.params.provider.*;
import org.w3c.dom.*;

public class CheckForChangesIT {

  private CertsToCheckEnum certToCheck;
  private Document doc;
  // ----------------------------------------------------
  @ParameterizedTest
  @EnumSource(CertsToCheckEnum.class)
  public void upToDate(CertsToCheckEnum c) throws Exception {
    certToCheck = c;
    String url = XML_URL + certToCheck.getExamNumber();
    try (InputStream stream = new URL(url).openStream()) {
      parseDocument(stream);
      String currentData = convertToString();
      assertSameAsExisting(currentData);
    }
  }

Key differences between JUnit 4 and 5 Parameterized Test

  • The JUnit 5 annotation has a different name and is placed on the test rather than the class. This is good because it lets you have some parameterized tests in a class and some regular tests. With JUnit 4, I had to arbitrarily create another class for the non-parameterized parts.
  • JUnit 5 has a number of annotations for building the parameter list without having to write custom code.
  • JUnit 5 injects the parameter as a method parameter rather than an instance variable.
    • In many ways this is nice. For example, I am now using a try-with-resources to close the stream rather than creating in @BeforeEach and having ugly logic to clean it up later. I could have done this in JUnit 4 but it seemed less natural.
    • In the case of my “legacy” test, I use the previously injected instance variable all over the class.  Hence my hack of storing the local variable in the original instance variable as the first line of my test method.
  • The JUnit 5 version is a good bit shorter

One problem

I encountered a minor Eclipse bug with parameterized tests. So I reported it.