Skip to content

Simplify CI builds #3084

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

Merged
merged 15 commits into from
Sep 9, 2017
Merged

Simplify CI builds #3084

merged 15 commits into from
Sep 9, 2017

Conversation

allanrenucci
Copy link
Contributor

No description provided.

@allanrenucci allanrenucci changed the title Drone Simplify CI builds Sep 7, 2017
Copy link
Contributor

@felixmulder felixmulder left a comment

Choose a reason for hiding this comment

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

How does the publishing relate to groups? Will all tests run and then the publishing? Or will it be "in the group" in some way?

Otherwise LGTM, and happy to see the new drone functionality get in so we can throw away the matrix build

SHOULD_RUN=true
CMD="$1"

if [ -z "$CMD" ]; then
Copy link
Contributor

Choose a reason for hiding this comment

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

Nitpick, this should be:

if [ -z ${CMD+x} ]; then

otherwise you can pass empty string here and it will accept it as valid input.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My understanding is that it is the other way around:

> FOO=""; if test -z ${FOO+x}; then echo "Empty"; else echo "Full"; fi
Full
> FOO=""; if test -z "$FOO"; then echo "Empty"; else echo "Full"; fi
Empty

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe I wasn't clear - you're testing if the variable FOO is empty string - instead of testing if the variable is set at all. E.g. setting FOO="" versus not setting it at all

:)

Copy link
Contributor

Choose a reason for hiding this comment

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

But seriously though, nitpick 😛

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I want the script to exit if the variable is not set or if it is an empty string. An empty cmd should be reject IMO. With -z "$CMD", it rejects both cases.

# PGP Credentials:
PGP_PW=$4
# Usage:
# SONATYPE_USER=<sonatype user> SONATYPE_PW=<sonatype pw> PGP_PW=<pgp pw> ./sbtPublish <publish cmd>
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@allanrenucci
Copy link
Contributor Author

Unfortunately there seems to be a major issue. The builds in the same group run in parallel but they share the same workspace... So they fail 😭
Maybe there is a way to not share the same workspace.

@felixmulder
Copy link
Contributor

Maybe there is a way to not share the same workspace.

Yeah, this was our original fear with the matrix builds as well - but turns out that the matrix build actually separates things 😂

@allanrenucci allanrenucci force-pushed the drone branch 4 times, most recently from 0f93cae to e68fdde Compare September 7, 2017 15:51
@smarter
Copy link
Member

smarter commented Sep 7, 2017

The ivy cache does not seem to be used anymore with this PR, in http://dotty-ci.epfl.ch/lampepfl/dotty/103/1/test everything gets downloaded.

@allanrenucci
Copy link
Contributor Author

@smarter Good catch. I was trying to understand the slow down, this might be the cause

fi

if [ $SHOULD_RUN = true ]; then
# get the ivy2 cache:
ln -s /var/cache/drone/ivy2 "$HOME/.ivy2" || true
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@felixmulder What was || true for?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this was just there to allow ln to fail, having a cache is not the most important thing to this script. It could definitely be removed, but we then loose the ability to test without /var/cache/drone/ivy2 being present - not a big deal I guess.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had the ln command run as an initial step before the tests but it was not persisted between the steps and the CI started re-downloading artifacts. So I added it in all the CI scripts

Copy link
Contributor

Choose a reason for hiding this comment

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

We used to have a common script that was sourced from the other scripts - if there's too much duplication, you could consider doing something similar eventually.

Copy link
Contributor

Choose a reason for hiding this comment

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

Note that ln also fails if "$HOME/.ivy2" already exists, so I think you might get spurious error messages in the log upon running the script the second time on the same container.

Copy link
Contributor

@felixmulder felixmulder Sep 8, 2017

Choose a reason for hiding this comment

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

Ah, true! That's exactly why, I remember now!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Does ln survive multiple steps? Because I tried to do it once before all the steps, but then the CI would redownload artifacts: http://dotty-ci.epfl.ch/lampepfl/dotty/102

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I will experiment

Copy link
Contributor

Choose a reason for hiding this comment

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

It doesn't seem so 🤔

Copy link
Contributor

@felixmulder felixmulder Sep 8, 2017

Choose a reason for hiding this comment

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

It does, however, survive within a single command section, IIRC

@allanrenucci
Copy link
Contributor Author

@felixmulder Can you review again. I managed to solve the issue of shared workspace by running each instance of sbt in its own directory

echo "Working directory: $PWD"

# get the ivy2 cache
ln -s /var/cache/drone/ivy2 "$HOME/.ivy2"
Copy link
Contributor

Choose a reason for hiding this comment

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

Just a thought that popped up - does it make sense to do the release builds without the cache?

cc: @smarter

Copy link
Member

Choose a reason for hiding this comment

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

does it make sense to do the release builds without the cache?

I don't see in what situation that could make a difference?

Copy link
Contributor

Choose a reason for hiding this comment

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

Corrupt cache causing issues with jars - that's why we chose to have it static rather than using the dynamic caching plugin. Other than that - I've got nothing :)

.drone.yml Outdated
group: test
image: lampepfl/dotty:2017-09-05
commands:
- cp -R . /tmp/0/ && cd /tmp/0/
Copy link
Contributor

Choose a reason for hiding this comment

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

I see you went for the shortest possible name here 😄

.drone.yml Outdated

publish_nightly:
image: lampepfl/dotty:2017-09-05
environment:
- NIGHTLYBUILD=yes
commands:
- ./project/scripts/sbt ";clean ;publishLocal" "${CI_PUBLISH}"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

publish does not publishLocal anymore. What was the reason for publishing locally here?

cc: @smarter @felixmulder

Copy link
Contributor

Choose a reason for hiding this comment

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

IIRC something to do with testing the SBT integrations, but I'll defer to @smarter

Copy link
Member

@smarter smarter Sep 8, 2017

Choose a reason for hiding this comment

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

I don't think publishLocal has been necessary for anything in a long time.

CMD=" ;set credentials in ThisBuild := Seq(Credentials(\"Sonatype Nexus Repository Manager\", \"oss.sonatype.org\", \"$2\", \"$3\"))"
CMD="$CMD ;set pgpPassphrase := Some(\"\"\"$4\"\"\".toCharArray)"
CMD="$CMD ;set pgpSecretRing := file(\"/keys/secring.asc\")"
CMD="$CMD ;set pgpPublicRing := file(\"/keys/pubring.asc\")"
CMD="$CMD $RELEASE_CMD"

# run sbt with the supplied arg
sbt -J-Xmx4096m \
Copy link
Member

Choose a reason for hiding this comment

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

Would be nice if there was less duplication between sbt and sbtPublish

Copy link
Member

@smarter smarter left a comment

Choose a reason for hiding this comment

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

Stuff is still being downloaded: http://dotty-ci.epfl.ch/lampepfl/dotty/115/1/test

@smarter
Copy link
Member

smarter commented Sep 8, 2017

Also probably unrelated to this PR but the CI logs used to be in color, what happened to that?

@allanrenucci
Copy link
Contributor Author

Stuff is still being downloaded

@smarter This happened also before this PR: http://dotty-ci.epfl.ch/lampepfl/dotty/116/3/test
It happens during the bootstrapped tests because when we generated the Dotty Docker image, we didn't compile with bootstrapped Dotty. I can address this in a separate PR

@allanrenucci
Copy link
Contributor Author

Also probably unrelated to this PR but the CI logs used to be in color, what happened to that?

I see colored logs. Maybe an issue with Firefox?

sbt -J-Xmx4096m \
-J-XX:ReservedCodeCacheSize=512m \
-J-XX:MaxMetaspaceSize=1024m \
-Ddotty.drone.mem=4096m \
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@felixmulder What is this option for?

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is it different than setting -J-Xmx4096m?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it. One is for the JVM running sbt and the other for the forked JVM for the tests

@allanrenucci allanrenucci force-pushed the drone branch 2 times, most recently from d012eea to 44ea37e Compare September 8, 2017 14:21
@allanrenucci
Copy link
Contributor Author

@smarter I removed the duplication in the scripts. If this looks good to you, I am merging it

# run sbt with the supplied arg
sbt -J-Xmx4096m \
-J-XX:ReservedCodeCacheSize=512m \
-J-XX:MaxMetaspaceSize=1024m \
-Ddotty.drone.mem=4096m "$CMD"
-Ddotty.drone.mem=4096m \
Copy link
Contributor

Choose a reason for hiding this comment

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

So we still use that thing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From what I understood, -J-Xmx4096m is an option passed to the VM that run sbt and Ddotty.drone.mem=4096m will be passed to the forked VMs

# run sbt with the supplied arg
sbt -J-Xmx4096m \
-J-XX:ReservedCodeCacheSize=512m \
-J-XX:MaxMetaspaceSize=1024m \
-Ddotty.drone.mem=4096m "$CMD"
-Ddotty.drone.mem=4096m \
-ivy /var/cache/drone/ivy2 \
Copy link
Contributor

Choose a reason for hiding this comment

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

I this doesn't do what you think it does. This way you still download all the dependence needed for sbt itself...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No sure about that. If you look at the CI test logs (except for test_bootstrapped), I don't see any download.

@smarter
Copy link
Member

smarter commented Sep 9, 2017

Would be good to make sure there is no speed loss by comparing master CI time and this branch CI time when nothing else is running.

@allanrenucci
Copy link
Contributor Author

No thorough benchmark but this PR took 12 min to build when nothing else was running. Looking at the history of the builds, build time is rarely under 12min.

@allanrenucci allanrenucci merged commit c53bcbc into scala:master Sep 9, 2017
allanrenucci added a commit that referenced this pull request Sep 9, 2017
allanrenucci added a commit that referenced this pull request Sep 9, 2017
allanrenucci added a commit to allanrenucci/dotty that referenced this pull request Sep 9, 2017
@allanrenucci allanrenucci deleted the drone branch September 9, 2017 16:36
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.

5 participants