Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add CD build pipeline #1

Merged
merged 44 commits into from
Jan 12, 2019
Merged

Add CD build pipeline #1

merged 44 commits into from
Jan 12, 2019

Conversation

sherifnada
Copy link
Contributor

@sherifnada sherifnada commented Jan 8, 2019

Context

CD pipeline should be ready to go now. To release a new version of this lib, we'll probably want to use the maven release plugin which moves the current version off of -SNAPSHOT. It'll temporarily change e.g 1.0-SNAPSHOT to 1.0, perform a deploy, then bump to 1.1-SNAPSHOT to resume development. It also has a bunch of other handy features that make life easier when deploying.

Structure of changes

.travis.yml: in order for the build to succeed, two things need to happen successfully:

  1. build and test the module
  2. sign artifacts and deploy them to Sonatype (which will mirror to Maven Central)

pom.xml: A few small details that the build needs. Perhaps most interesting is the sign profile.

cd/mvnsettings.xml: Specifies the environment variables that will be injected at build time for use in signing and publishing artifacts.

*.java: just a bunch of changes I had to make to get the build working. Ignore the java files since they'll be revamped in future PRs this week.

Misc

I'd love any comments on readability/accessibility of the non java code.

Potential Improvements

  • I think it would also be good to add some notes in the README or elsewhere specifying the dev workflow when editing this repo (i.e: how do you make sure everything short of deploying to maven central works? How do you release etc..).

pom.xml Outdated
<build>
<!-- Be explicit about where maven should look for source and test files -->
<sourceDirectory>src/main/java</sourceDirectory>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't this the default?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is. I thought it was confusing that the Maven default is for tests to have a different structure (test/java) than source code (src/main/java), so I wanted to make these two lines explicit just to be clear.

Though this being said, my hunch is that while it may be nice in the short term, over time this kind of cruft (explicit specification instead of convention) could build up. This makes me think there's no reason to even use the non-default directories since it just means I have to add more to my POM without much of a gain (if it's confusing that src and tst have different dirs, well, blame it on Maven :D ).

Do you think it's better to call these out like this or just use convention? You've definitely had more experience maintaining POMs than I have.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would strongly prefer to use maven defaults unless we have functional reasons for changing it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Contributor

@ChristianHansen ChristianHansen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments, mostly nit-picks.
Thanks for getting this working and including comments in the pom.

cd/deploy.sh Outdated
openssl aes-256-cbc -K $encrypted_9718d3d48d9b_key -iv $encrypted_9718d3d48d9b_iv -in $TRAVIS_BUILD_DIR/cd/codesigning.asc.enc -out $TRAVIS_BUILD_DIR/cd/codesigning.asc -d || exit 1;

# import these certs into GPG
gpg --fast-import $TRAVIS_BUILD_DIR/cd/codesigning.asc || exit 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could do set -e at the beginning of this script so it exits if any commands return a non-zero exit code. That way, you don't need the || exit 1.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the tip!

cd/deploy.sh Outdated
gpg --fast-import $TRAVIS_BUILD_DIR/cd/codesigning.asc || exit 1;

# Remove the unencrypted cert file
rm cd/codesigning.asc || exit 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to ensure this is always deleted, no matter what?
You could do trap 'rm cd/codesigning.acs' EXIT right after the openssl command to ensure this file is always deleted on exit.

cd/deploy.sh Outdated
# Note that if any of these commands fail, we exit so we get quick feedback from the build.

# First, unencrypt the certs we'll use to sign artifacts
openssl aes-256-cbc -K $encrypted_9718d3d48d9b_key -iv $encrypted_9718d3d48d9b_iv -in $TRAVIS_BUILD_DIR/cd/codesigning.asc.enc -out $TRAVIS_BUILD_DIR/cd/codesigning.asc -d || exit 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it's generally a best practice to put double-quotes around interpolated vars in Bash to prevent word-splitting or globbing. Also, I'd recommend using curly braces e.g. ${TRAVIS_BUILD_DIR} in general, since it makes it very explicit what the interpolated var is an prevents sneaky bugs from typos like $TRAVIS_BUILD_DIRcd evaluating to "".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I use shellcheck to help catch stuff like this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks for pointing out shellcheck. These are all good points.

<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we just uber-jarring here, or is there actual shading needed? Can we have comment explaining this?

import org.junit.Test;

import java.nio.charset.StandardCharsets;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's talk offline, but we should probably sync on our code-formatting settings so we don't have a bunch of formatting only-diffs

long result = BetaMinHash.intersection(sk1, sk2);

double pctError = 100 * getError(result, expected);
double expectedPctError = 5.0;
assertTrue(String.format("Expected error ratio to be at most %s but found %f", expectedPctError, pctError),
assertTrue(
String.format("Expected error ratio to be at most %s but found %f", expectedPctError,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this was just the IntelliJ formatter gone rogue, but it would be nice to stick to one-arg-per-line if we're splitting over multiple lines.

@@ -144,7 +143,8 @@ public void testManyWayIntersection() {
long actualIntersection = BetaMinHash.intersection(sk1, sk2, sk3);
double pctError = 100 * getError(actualIntersection, expectedIntersection);
assertTrue(
String.format("Expected pctError to be <2, found %f. Expected: %d, Actual: %d", pctError, expectedIntersection, actualIntersection),
String.format("Expected pctError to be <2, found %f. Expected: %d, Actual: %d", pctError,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comment as above

.travis.yml Outdated
script:
# First install any deps and runs tests
- mvn clean install test -P-build-src-and-docs -B -V
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we package instead of install? (not sure)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to package since there is no need to install into the .m2 cache

Copy link
Contributor

@ChristianHansen ChristianHansen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the Java formatting changes are addressed in #2, LGTM

cd/deploy.sh Outdated
#! /usr/bin/env bash

# TODO comment this back in
#if [ "$TRAVIS_BRANCH" = 'master' ] && [ "$TRAVIS_PULL_REQUEST" == 'false' ]; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comment this back in?

@sherifnada sherifnada merged commit f668b03 into master Jan 12, 2019
@sherifnada sherifnada deleted the prep-release branch February 21, 2019 23:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants