-
Notifications
You must be signed in to change notification settings - Fork 13
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
Conversation
….asc.enc containing encrypted GPG keys
This way, if publishing fails, then so will the build.
pom.xml
Outdated
<build> | ||
<!-- Be explicit about where maven should look for source and test files --> | ||
<sourceDirectory>src/main/java</sourceDirectory> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this 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; |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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 ""
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comment this back in?
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.g1.0-SNAPSHOT
to1.0
, perform a deploy, then bump to1.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:pom.xml
: A few small details that the build needs. Perhaps most interesting is thesign
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