Skip to content

Drone to GitHub Actions Migration #8353

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

Closed
10 tasks done
anatoliykmetyuk opened this issue Feb 20, 2020 · 4 comments · Fixed by #8791 or #8793
Closed
10 tasks done

Drone to GitHub Actions Migration #8353

anatoliykmetyuk opened this issue Feb 20, 2020 · 4 comments · Fixed by #8791 or #8793
Assignees
Labels
area:infrastructure itype:meta Issues about process/similar

Comments

@anatoliykmetyuk
Copy link
Contributor

anatoliykmetyuk commented Feb 20, 2020

The process takes several steps:

  • Run test, test_bootstrapped, and community_build on GH Actions on each push and PR event. Also, run sbt and java11 tests on tags (probably won't happen until next release). The runs happen on our machines.
  • Release nightly builds from GitHub Actions. Generate the documentation for them. Disable CRON job that triggers the nightly builds on Drone and use GitHub Actions scheduler instead.
  • Make Dotty releases a responsibility of GitHub Actions, transition their execution on our machines and ditch Drone CI altogether.
  • Implement SBT plugin release capability.

Cleanup work to be done after the migration is finished:

  • Drop "update" command from tests. It was needed for the caching of jars which involved generating a new docker image on each dependency update. GH Actions uses a different caching strategy so "update" becomes unneeded.
  • Upload a new docker image, without the cache, to LAMP's Dockerhub organization. Currently, the one uploaded to my account is used.
  • Describe the setup in a separate repo, similarly to how it is done with lampepfl/dotty-drone for Drone.
  • Rerun failing community tests a few times if they fail to mitigate concurrency effects. Is relevant for the Intent framework which is prone to spontaneous failures due to exceeded timeouts.
  • Caching: check the logs of the jobs and ensure they don't do unnecessary fetching from the Internet, everything should be cached.
  • Abstract the cleanup step into a shell script.
@anatoliykmetyuk anatoliykmetyuk added the itype:meta Issues about process/similar label Feb 20, 2020
@anatoliykmetyuk anatoliykmetyuk self-assigned this Feb 20, 2020
@smarter
Copy link
Member

smarter commented Feb 22, 2020

The community build run through github ci is failing on all PRs currently with:

2020-02-22T14:51:41.0354955Z [32m./mill -i -D dottyVersion=0.23.0-bin-SNAPSHOT utest.jvm[0.23.0-bin-SNAPSHOT].publishLocal[0m
2020-02-22T14:51:41.9949313Z Compiling (synthetic)/ammonite/predef/interpBridge.sc
2020-02-22T14:51:46.7616899Z Compiling (synthetic)/ammonite/predef/sourceBridge.sc
2020-02-22T14:51:47.6162673Z Compiling (synthetic)/ammonite/predef/frontEndBridge.sc
2020-02-22T14:51:48.1342260Z Compiling (synthetic)/ammonite/predef/DefaultPredef.sc
2020-02-22T14:51:48.7483567Z Compiling /__w/dotty/dotty/community-build/community-projects/utest/build.sc
2020-02-22T14:51:53.2390234Z [1/46] utest.jvm[0.23.0-bin-SNAPSHOT].resources 
2020-02-22T14:51:53.2677879Z [1A[2K[9999D[4/46] mill.scalalib.ZincWorkerModule.worker 
2020-02-22T14:51:53.3193569Z 1 targets failed
2020-02-22T14:51:53.3194004Z mill.scalalib.ZincWorkerModule.worker java.lang.ClassNotFoundException: mill.scalalib.worker.ZincWorkerImpl
2020-02-22T14:51:53.3199226Z     java.net.URLClassLoader.findClass(URLClassLoader.java:382)
2020-02-22T14:51:53.3199727Z     mill.api.ClassLoader$$anon$1.super$findClass(ClassLoader.scala:27)
2020-02-22T14:51:53.3200050Z     mill.api.ClassLoader$$anon$1.$anonfun$findClass$1(ClassLoader.scala:27)
2020-02-22T14:51:53.3200261Z     scala.Option.getOrElse(Option.scala:138)
2020-02-22T14:51:53.3200458Z     mill.api.ClassLoader$$anon$1.findClass(ClassLoader.scala:27)
2020-02-22T14:51:53.3200681Z     java.lang.ClassLoader.loadClass(ClassLoader.java:419)
2020-02-22T14:51:53.3200919Z     java.lang.ClassLoader.loadClass(ClassLoader.java:352)
2020-02-22T14:51:53.3201125Z     mill.scalalib.ZincWorkerModule.$anonfun$worker$2(ZincWorkerModule.scala:46)
2020-02-22T14:51:53.3835813Z [error] Test dotty.communitybuild.CommunityBuildTest.oslib failed: java.lang.RuntimeException: Publish command exited with code 1 for project utest. Project details:
2020-02-22T14:51:53.3837202Z [error] MillCommunityProject(utest,utest.jvm[0.23.0-bin-SNAPSHOT],List()), took 12.347 sec
2020-02-22T14:51:53.3837401Z [error]     at dotty.communitybuild.CommunityProject.publish(CommunityBuildTest.scala:76)
2020-02-22T14:51:53.3837970Z [error]     at dotty.communitybuild.MillCommunityProject.publish(CommunityBuildTest.scala:80)
2020-02-22T14:51:53.3839584Z [error]     at dotty.communitybuild.CommunityProject.run$$anonfun$1(CommunityBuildTest.scala:65)

@smarter
Copy link
Member

smarter commented Feb 22, 2020

My guess is that the mill cache is incomplete or corrupt in some way.

@smarter
Copy link
Member

smarter commented Feb 22, 2020

also can we configure github actions to not send an email when something fails ?

@anatoliykmetyuk
Copy link
Contributor Author

My guess is that the mill cache is incomplete or corrupt in some way.

That's what I also suspected at first. However, running the build without the Mill cache didn't seem to solve the problem. Also in certain cases the build just randomly passed.

also can we configure github actions to not send an email when something fails ?

I believe this is only possible on the profile-level for each person individually, in your settings: https://github.com/settings/notifications

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:infrastructure itype:meta Issues about process/similar
Projects
None yet
2 participants