Git Product home page Git Product logo

aws-lambda-github-merge's Introduction

Merging pull requests on AWS Lambda with GitHub webhooks

build

The following Scala code builds a Java JAR file that can run on AWS Lambda to automatically continuously integrate pull requests for a GitHub project.

Overview

A Scala program that is tightly coupled to the following libraries:

  • The Java library, JGit, by Eclipse can clone Git repositories, checkout branches, merge them and push them.
  • The Java library, JSch, from JCraft provides SSH support for JGit including support for user and host key verification.
  • Use of the GitHub API is with a Scala library, github-api, by SHUNJI Konishi of Codecheck.
  • Connect to GitHub's API over HTTP with a Java library, Async HTTP Client, by Ning.
  • JSON serialization with the Scala library, json4s, by Ivan Porto Carrero and KAZUHIRO Sera.
  • The AWS Lambda Java libraries by Amazon AWS provide the ability to run the JAR in their serverless Java 8 runtime.
  • JAR produced using the SBT plugin, SBT Assembly, by Eugene Yokota.
  • JVM file system housekeeping provided by the sbt.io Scala library, from SBT team at Lightbend, Inc.
  • Configuration file support managed by knobs from Verizon and Typesafe Config from Lightbend, Inc.
  • Logging provided by SLF4J of QoS.ch and Typesafe Scala Logging by Lightbend, Inc.

Steps in detail:

  • Receive event from GitHub by way of AWS API Gateway request
  • Load config file from application.conf
  • Verify repo in request is same repo in config file
  • Find name of base branch in config file to merge on to
  • Use GitHub token in config file to call GitHub API
  • Find all pull requests in the repo for the base branch
  • Set HEAD commit to all pull requests to pending
  • Checkout base branch with Git and SSH
  • Use SSH keys and known_hosts specified in config file
  • Use SSH keys and known_hosts included in JAR file
  • Create integration branch specified in config file with Git
  • Merge pull requests on to integration branch with Git
  • Force push to GitHub using Git and SSH
  • If merge succeeds, merged branches
  • If merge fails, don't push, and return unmergable branch
  • Notify success or failure with GitHub status API

Installing

For deploying the JAR see the INSTALLING file for instructions.

Contributing

For development tasks see the CONTRIBUTING file.

Warranty

Buyer beware: This application will overwrite Git branches. Should the merge complete successfully, the application does a forced push to a branch of a remote Git repo. The branch is the one that is configured in application.conf. A forced push could result in data loss. The SSH deploy user key added to GitHub will have access to all the repos the user is configured for. However, by the nature of private repos in GitHub, write access to a root repo in GitHub will provide the same access to forked repos. This is advantageous since the program requires read-access to forks. Public repos provide read-access, by default, without a deploy key for any GitHub user. Since this program requires write-access to the repo configured in application.conf, the deploy user key will have write-access to forks of private all repos that user has access to.

The code will verify that the Git repo specified in application.conf, including the branch to monitor for pull requests.

The application as written doesn't catch any exceptions. There's no need for the program to recover given it is an internal task that runs in AWS Lambda, a serverless environment.

The SSH key used to pull from private repos or push to repositories, is included in the JAR file. This is a security concern, since the SSH key will have write privileges to remote Git repositories at GitHub.

Currently, if there is an error then it results in an exception being thrown and execution being halted.

Some of the failure conditions that should be caught with a friendly error message, include

  • Unable to read or write to temporary directory on filesystem
  • Conf file missing from JAR
  • Conf file missing directives
  • API Gateway json is malformed
  • GitHub json is malformed
  • SSH keys missing from the JAR
  • SSH hosts key file, known_hosts, is missing from JAR
  • SSH host key verification fails
  • Git client is broken or unavailable
  • Git server is broken or unavailable
  • A Git remote doesn't exist
  • Base branch doesn't exist
  • HTTP is broken or unavailable
  • GitHub API is broken or unavailable
  • Configuring Git remotes fails
  • Git fetching fails
  • Checking out remote branch fails
  • Git merge fails
  • Git push to remote fails

References

aws-lambda-github-merge's People

Contributors

ashawley avatar dependabot[bot] avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar

Forkers

cescude

aws-lambda-github-merge's Issues

Add details link to status

Right now, if the merge succeeds it says, "Continuous integration succeeded", or if it fails, "Failed to merge user-one:fix-2589: Conflicting". It would be nice to show the full log of the merge attempt.

This is an involved task, because (1) the log output needs to be extracted out (2) it needs to be web published somewhere, then (3) it's published location needs to added to the status API call.

Check mergeability before merging

  • GitHub PRs have a mergeable field.
  • This should be checked for each of the candidate PRS
  • If mergeable is set to false for one or more PRs, then set their status to pending

Git submodules

If a branch introduces a git submodule, then merging will fail. Presumably, because the program doesn't have access to the submodule's repository. This lack of access will be much more likely the case if the repository of the submodule is a private one.

Where b5677c9970d628790993460a681e8239bf133d3f is the submodule's HEAD commit, the program will produce this error:

org.eclipse.jgit.errors.MissingObjectException: Missing unknown b5677c9970d628790993460a681e8239bf133d3f

Support for git submodules needs to be provided, and/or give a better error message when a git submodule is detected.

GitHub Services discontinued

AWS Lambda used to be triggered by the SNS integration in GitHub. This went away on 31-Jan, 2019. They announced it on 25-Apr, 2018.

https://developer.github.com/changes/2018-04-25-github-services-deprecation/

Will need to find a new solution.

Would probably involve webhooks:

https://developer.github.com/webhooks/

There is a way to set up a webhook in API Gateway and have it trigger AWS Lambda:

https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-getting-started-with-rest-apis.html

PRs with deleted fork

When a PR's fork is deleted by the fork's owner, the PR says the branch is "unknown repository". When querying the GitHub api about the open PRs, the branch repo info is unavailable (pr.head.repo is null). Admittedly, there's probably no way around this unfortuitous situation. It requires manual intervention to either merge the PR, or re-open the PR with the branch in an available repo. There's a chance that one could use the GitHub API find an alternate way to somehow find git refs to merge. However, what's unacceptable is the error message in this situation:

ERROR prs.Main$:230 - java.util.NoSuchElementException: None.get 

A more helpful error message could be "No repo information found for pull request: owner/project#123"

GitHub token env vars

  • Objective: Store GitHub token in encrypted environment variables in AWS
  • Presently, GitHub token is stored in configuration file.
  • Rationale: AWS encrypted variables are more secure and can be updated easier without a need for a new build to be uplaoded.
  • Safety: If the variable isn't in the environment variable, then fail gracefully.
  • Safety: If the variable isn't in the environment variable, try the config file?
  • Configuration: Document use of AWS Lambda environment variables.
  • Configuration: Document use of env locally for local development.

java.io.IOException: Closed

I have an AWS Lambda function running in us-east-1 that occasionally fails to connect to GitHub's HTTP API. It most often fails on the first API call, which is the endpoint /repos/SpeakEZ/speakez-rails/pulls. After that failure, the AWS Lambda function halts.

START RequestId: ed8e9386-4c53-11e7-8916-3be6d53816d3 Version: $LATEST
14:08:21.199 <ed8e9386-4c53-11e7-8916-3be6d53816d3> [main] INFO  prs.Main$:109 - Starting aws-gh-prs 0.1-SNAPSHOT
14:08:21.199 <ed8e9386-4c53-11e7-8916-3be6d53816d3> [main] INFO  prs.Main$:111 - Inspecting SNS notification...
14:08:21.242 <ed8e9386-4c53-11e7-8916-3be6d53816d3> [main] INFO  prs.Main$:120 - Processed 1 event(s)
14:08:21.260 <ed8e9386-4c53-11e7-8916-3be6d53816d3> [main] INFO  prs.Main$:165 - Pull request was SpeakEZ/master..ashawley/CAP-2052
14:08:21.260 <ed8e9386-4c53-11e7-8916-3be6d53816d3> [main] INFO  prs.Main$:239 - Querying GitHub for open pull request(s)...
14:08:21.261 <ed8e9386-4c53-11e7-8916-3be6d53816d3> [main] DEBUG com.ning.http.client.AsyncCompletionHandler:60 - Closed
14:08:21.358 <ed8e9386-4c53-11e7-8916-3be6d53816d3> [main] ERROR prs.Main$:233 - Failed for unexpected reason
java.io.IOException: Closed
	at com.ning.http.client.providers.netty.request.NettyRequestSender.sendRequest(NettyRequestSender.java:98)
	at com.ning.http.client.providers.netty.NettyAsyncHttpProvider.execute(NettyAsyncHttpProvider.java:87)
	at com.ning.http.client.AsyncHttpClient.executeRequest(AsyncHttpClient.java:506)
	at com.ning.http.client.AsyncHttpClient$BoundRequestBuilder.execute(AsyncHttpClient.java:225)
	at codecheck.github.transport.asynchttp19.AsyncHttp19Request.execute(AsyncHttp19Transport.scala:41)
	at codecheck.github.api.GitHubAPI.exec(GitHubAPI.scala:66)
	at codecheck.github.operations.PullRequestOp$class.listPullRequests(PullRequestOp.scala:28)
	at codecheck.github.api.GitHubAPI.listPullRequests(GitHubAPI.scala:21)
	at prs.Main$.mergeFor(Main.scala:247)
	at prs.Main$$anonfun$2$$anonfun$5.apply(Main.scala:175)
	at prs.Main$$anonfun$2$$anonfun$5.apply(Main.scala:172)
	at scala.collection.TraversableLike$WithFilter$$anonfun$map$2.apply(TraversableLike.scala:683)
	at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
	at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
	at scala.collection.TraversableLike$WithFilter.map(TraversableLike.scala:682)
	at prs.Main$$anonfun$2.apply(Main.scala:172)
	at prs.Main$$anonfun$2.apply(Main.scala:106)
	at scala.util.Try$.apply(Try.scala:192)
	at prs.Main$.handler(Main.scala:106)
	at prs.Main.handler(Main.scala)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at lambdainternal.EventHandlerLoader$PojoMethodRequestHandler.handleRequest(EventHandlerLoader.java:456)
	at lambdainternal.EventHandlerLoader$PojoHandlerAsStreamHandler.handleRequest(EventHandlerLoader.java:375)
	at lambdainternal.EventHandlerLoader$2.call(EventHandlerLoader.java:1139)
	at lambdainternal.AWSLambda.startRuntime(AWSLambda.java:278)
	at lambdainternal.AWSLambda.<clinit>(AWSLambda.java:62)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at lambdainternal.LambdaRTEntry.main(LambdaRTEntry.java:94)
END RequestId: ed8e9386-4c53-11e7-8916-3be6d53816d3
REPORT RequestId: ed8e9386-4c53-11e7-8916-3be6d53816d3	Duration: 1134.79 ms
       Billed Duration: 1200 ms 	Memory Size: 384 MB	Max Memory Used: 384 MB	

It seems the HTTP client is not retrying the request or waiting on a timeout. It is pretty sudden. I've inspected the source code of the Ning/AHC library:

https://github.com/AsyncHttpClient/async-http-client/blob/1.9.x/src/main/java/com/ning/http/client/providers/netty/request/NettyRequestSender.java

https://github.com/AsyncHttpClient/async-http-client/blob/1.9.x/src/main/java/com/ning/http/client/providers/netty/NettyAsyncHttpProvider.java

For some reason the connection is in a closed state right away.

Coincidentally, AWS Lambda will re-run a function if it fails. Typically it will retry twice. However, the subsequent tries by AWS Lambda doesn't usually improve anything.

Log commit ids

The short refs for the branches used and the resulting integration branch should be added to the output for auditing purposes.

Right now, a log wouldn't be to distinct from another run. Here's a representative log.

START RequestId: 8bf110e9-f55b-11e7-a8fa-ed2fde25d236 Version: $LATEST
16:38:42.931 INFO prs.Main$:109 - Starting aws-gh-prs 0.3
16:38:43.010 INFO prs.Main$:111 - Inspecting SNS notification...
16:38:43.371 INFO prs.Main$:120 - Processed 1 event(s)
16:38:44.932 INFO prs.Main$:165 - Pull request was MainRepo/master..UserOne/fix-2462
16:38:44.970 INFO prs.Main$:244 - Querying GitHub for open pull request(s)...
16:38:55.231 INFO prs.Main$:266 - Found 19 pull request(s)
16:38:55.232 INFO prs.Main$:177 - Setting status on pull request(s)...
16:38:59.441 INFO prs.Main$:193 - Pending status set to pull request(s)
16:38:59.443 INFO prs.Main$:284 - Working directory is /tmp/sbt_7527e7f1
16:38:59.443 INFO prs.Main$:288 - Free space is 525M
16:38:59.443 INFO prs.Main$:290 - Cloning [email protected]:MainRepo/mainRepo.git...
16:41:02.050 INFO prs.Main$:303 - Configuring repository...
16:41:02.051 INFO prs.Main$:310 - Set user to MainUser
16:41:02.051 INFO prs.Main$:311 - Set email to [email protected]
16:41:02.051 INFO prs.Main$:313 - Configuring remotes...
16:41:02.110 INFO prs.Main$:324 - Remote cescude at [email protected]:UserTwo/mainRepo.git
16:41:02.113 INFO prs.Main$:324 - Remote UserThree at [email protected]:UserThree/mainRepo.git
16:41:02.113 INFO prs.Main$:324 - Remote UserOne at [email protected]:UserOne/mainRepo.git
16:41:02.131 INFO prs.Main$:335 - Configured 3 remote(s)
16:41:02.132 INFO prs.Main$:342 - Fetching UserOne:fix-2307...
16:41:15.110 INFO prs.Main$:342 - Fetching UserOne:fix-2329...
16:41:18.251 INFO prs.Main$:342 - Fetching UserTwo:fix-2337...
16:41:21.854 INFO prs.Main$:342 - Fetching UserOne:fix-2340...
16:41:23.153 INFO prs.Main$:342 - Fetching UserOne:wip-251...
16:41:24.031 INFO prs.Main$:342 - Fetching UserThree:fix-2005...
16:41:25.554 INFO prs.Main$:342 - Fetching UserThree:fix-2365...
16:41:26.651 INFO prs.Main$:342 - Fetching UserThree:fix-2401...
16:41:27.890 INFO prs.Main$:342 - Fetching UserThree:fix-2405...
16:41:28.711 INFO prs.Main$:342 - Fetching UserTwo:fix-2388...
16:41:29.370 INFO prs.Main$:342 - Fetching UserThree:fix-2428...
16:41:30.670 INFO prs.Main$:342 - Fetching UserTwo:fix-2435...
16:41:31.430 INFO prs.Main$:342 - Fetching UserTwo:fix-1815...
16:41:32.094 INFO prs.Main$:342 - Fetching UserTwo:fix-2459...
16:41:32.714 INFO prs.Main$:342 - Fetching UserThree:fix-2454...
16:41:33.450 INFO prs.Main$:342 - Fetching UserThree:fix-2458...
16:41:34.150 INFO prs.Main$:342 - Fetching UserThree:fix-2284...
16:41:34.734 INFO prs.Main$:342 - Fetching UserOne:fix-2461...
16:41:36.331 INFO prs.Main$:342 - Fetching UserOne:fix-2462...
16:41:37.790 INFO prs.Main$:355 - Checking out MainRepo/master...
16:41:38.852 INFO prs.Main$:363 - Creating branch staging...
16:41:40.151 INFO prs.Main$:374 - Merging UserOne/fix-2307...
16:41:41.432 INFO prs.Main$:374 - Merging UserOne/fix-2329...
16:41:44.133 INFO prs.Main$:374 - Merging UserTwo/fix-2337...
16:41:49.115 INFO prs.Main$:374 - Merging UserOne/fix-2340...
16:41:50.460 INFO prs.Main$:374 - Merging UserOne/wip-251...
16:41:54.155 INFO prs.Main$:374 - Merging UserThree/fix-2005...
16:41:57.232 INFO prs.Main$:374 - Merging UserThree/fix-2365...
16:41:58.572 INFO prs.Main$:374 - Merging UserThree/fix-2401...
16:41:59.833 INFO prs.Main$:374 - Merging UserThree/fix-2405...
16:42:01.532 INFO prs.Main$:374 - Merging UserTwo/fix-2388...
16:42:03.112 INFO prs.Main$:374 - Merging UserThree/fix-2428...
16:42:03.752 INFO prs.Main$:374 - Merging UserTwo/fix-2435...
16:42:04.651 INFO prs.Main$:374 - Merging UserTwo/fix-1815...
16:42:06.111 INFO prs.Main$:374 - Merging UserTwo/fix-2459...
16:42:06.452 INFO prs.Main$:374 - Merging UserThree/fix-2454...
16:42:06.791 INFO prs.Main$:374 - Merging UserThree/fix-2458...
16:42:07.230 INFO prs.Main$:374 - Merging UserThree/fix-2284...
16:42:07.551 INFO prs.Main$:374 - Merging UserOne/fix-2461...
16:42:07.956 INFO prs.Main$:374 - Merging UserOne/fix-2462...
16:42:08.311 INFO prs.Main$:424 - Pushing staging...
16:42:16.530 INFO prs.Main$:433 - Setting status on pull request(s)...
16:42:20.877 INFO prs.Main$:449 - Success status set to pull request(s)
16:42:20.880 INFO prs.Main$:224 - Closing async HTTP client
END RequestId: 8bf110e9-f55b-11e7-a8fa-ed2fde25d236
REPORT RequestId: 8bf110e9-f55b-11e7-a8fa-ed2fde25d236
       Duration: 220450.53 ms
       Billed Duration: 220500 ms
       Memory Size: 384 MB
       Max Memory Used: 384 MB

Commit ids could be added to the end of the checking out, merging and pushing entries:

START RequestId: 8bf110e9-f55b-11e7-a8fa-ed2fde25d236 Version: $LATEST
16:38:42.931 INFO prs.Main$:109 - Starting aws-gh-prs 0.3
16:38:43.010 INFO prs.Main$:111 - Inspecting SNS notification...
16:38:43.371 INFO prs.Main$:120 - Processed 1 event(s)
16:38:44.932 INFO prs.Main$:165 - Pull request was MainRepo/master..UserOne/fix-2462@2db7273 
16:38:44.970 INFO prs.Main$:244 - Querying GitHub for open pull request(s)...
16:38:55.231 INFO prs.Main$:266 - Found 19 pull request(s)
16:38:55.232 INFO prs.Main$:177 - Setting status on pull request(s)...
16:38:59.441 INFO prs.Main$:193 - Pending status set to pull request(s)
16:38:59.443 INFO prs.Main$:284 - Working directory is /tmp/sbt_7527e7f1
16:38:59.443 INFO prs.Main$:288 - Free space is 525M
16:38:59.443 INFO prs.Main$:290 - Cloning [email protected]:MainRepo/mainRepo.git...
16:41:02.050 INFO prs.Main$:303 - Configuring repository...
16:41:02.051 INFO prs.Main$:310 - Set user to MainUser
16:41:02.051 INFO prs.Main$:311 - Set email to [email protected]
16:41:02.051 INFO prs.Main$:313 - Configuring remotes...
16:41:02.110 INFO prs.Main$:324 - Remote cescude at [email protected]:UserTwo/mainRepo.git
16:41:02.113 INFO prs.Main$:324 - Remote UserThree at [email protected]:UserThree/mainRepo.git
16:41:02.113 INFO prs.Main$:324 - Remote UserOne at [email protected]:UserOne/mainRepo.git
16:41:02.131 INFO prs.Main$:335 - Configured 3 remote(s)
16:41:02.132 INFO prs.Main$:342 - Fetching UserOne:fix-2307@ad1aa63...
16:41:15.110 INFO prs.Main$:342 - Fetching UserOne:fix-2329@2b9848d...
16:41:18.251 INFO prs.Main$:342 - Fetching UserTwo:fix-2337@632bdef...
16:41:21.854 INFO prs.Main$:342 - Fetching UserOne:fix-2340@1843c40...
16:41:23.153 INFO prs.Main$:342 - Fetching UserOne:wip-251@268b153...
16:41:24.031 INFO prs.Main$:342 - Fetching UserThree:fix-2005@7937a6a...
16:41:25.554 INFO prs.Main$:342 - Fetching UserThree:fix-2365@87573ff...
16:41:26.651 INFO prs.Main$:342 - Fetching UserThree:fix-2401@e05e4b7...
16:41:27.890 INFO prs.Main$:342 - Fetching UserThree:fix-2405@7cae7ef...
16:41:28.711 INFO prs.Main$:342 - Fetching UserTwo:fix-2388@06d9fb7...
16:41:29.370 INFO prs.Main$:342 - Fetching UserThree:fix-2428@ddfd393...
16:41:30.670 INFO prs.Main$:342 - Fetching UserTwo:fix-2435@06d7b82...
16:41:31.430 INFO prs.Main$:342 - Fetching UserTwo:fix-1815@d6a4f5b...
16:41:32.094 INFO prs.Main$:342 - Fetching UserTwo:fix-2459@9b8a3f7...
16:41:32.714 INFO prs.Main$:342 - Fetching UserThree:fix-2454@c21a0cc...
16:41:33.450 INFO prs.Main$:342 - Fetching UserThree:fix-2458@d031a03...
16:41:34.150 INFO prs.Main$:342 - Fetching UserThree:fix-2284@0dd03dd...
16:41:34.734 INFO prs.Main$:342 - Fetching UserOne:fix-2461@b4d2257...
16:41:36.331 INFO prs.Main$:342 - Fetching UserOne:fix-2462@3ff1301...
16:41:37.790 INFO prs.Main$:355 - Checking out MainRepo/master@14ed192...
16:41:38.852 INFO prs.Main$:363 - Creating branch staging@14ed192...
16:41:40.151 INFO prs.Main$:374 - Merging UserOne/fix-2307...
16:41:41.432 INFO prs.Main$:374 - Merging UserOne/fix-2329...
16:41:44.133 INFO prs.Main$:374 - Merging UserTwo/fix-2337...
16:41:49.115 INFO prs.Main$:374 - Merging UserOne/fix-2340...
16:41:50.460 INFO prs.Main$:374 - Merging UserOne/wip-251...
16:41:54.155 INFO prs.Main$:374 - Merging UserThree/fix-2005...
16:41:57.232 INFO prs.Main$:374 - Merging UserThree/fix-2365...
16:41:58.572 INFO prs.Main$:374 - Merging UserThree/fix-2401...
16:41:59.833 INFO prs.Main$:374 - Merging UserThree/fix-2405...
16:42:01.532 INFO prs.Main$:374 - Merging UserTwo/fix-2388...
16:42:03.112 INFO prs.Main$:374 - Merging UserThree/fix-2428...
16:42:03.752 INFO prs.Main$:374 - Merging UserTwo/fix-2435...
16:42:04.651 INFO prs.Main$:374 - Merging UserTwo/fix-1815...
16:42:06.111 INFO prs.Main$:374 - Merging UserTwo/fix-2459...
16:42:06.452 INFO prs.Main$:374 - Merging UserThree/fix-2454...
16:42:06.791 INFO prs.Main$:374 - Merging UserThree/fix-2458...
16:42:07.230 INFO prs.Main$:374 - Merging UserThree/fix-2284...
16:42:07.551 INFO prs.Main$:374 - Merging UserOne/fix-2461...
16:42:07.956 INFO prs.Main$:374 - Merging UserOne/fix-2462...
16:42:08.311 INFO prs.Main$:424 - Pushing staging@fc71b06...
16:42:16.530 INFO prs.Main$:433 - Setting status on pull request(s)...
16:42:20.877 INFO prs.Main$:449 - Success status set to pull request(s)
16:42:20.880 INFO prs.Main$:224 - Closing async HTTP client
END RequestId: 8bf110e9-f55b-11e7-a8fa-ed2fde25d236
REPORT RequestId: 8bf110e9-f55b-11e7-a8fa-ed2fde25d236
       Duration: 220450.53 ms
       Billed Duration: 220500 ms
       Memory Size: 384 MB
       Max Memory Used: 384 MB

No space left on device

Apparently, AWS has a limited amount of space on the /tmp device and can fill up:

13:36:03.148 [main] INFO prs.Main$:109 - Starting aws-gh-prs 0.2
13:36:03.169 [main] INFO prs.Main$:111 - Inspecting SNS notification...
13:36:03.528 [main] INFO prs.Main$:120 - Processed 1 event(s)
13:36:03.809 [main] INFO prs.Main$:165 - Pull request was upstream/master..origin/hotfix
13:36:03.827 [main] INFO prs.Main$:244 - Querying GitHub for open pull request(s)...
13:36:14.528 [main] INFO prs.Main$:266 - Found 17 pull request(s)
13:36:14.529 [main] INFO prs.Main$:177 - Setting status on pull request(s)...
13:36:18.555 [main] INFO prs.Main$:193 - Pending status set to pull request(s)
13:36:18.628 [main] INFO prs.Main$:284 - Working directory is /tmp/sbt_59934c5f
13:36:18.628 [main] INFO prs.Main$:286 - Cloning [email protected]:org/proj.git...
13:37:35.368 [main] ERROR prs.Main$:200 - No space left on device
13:37:35.386 [main] INFO prs.Main$:202 - Setting status on pull request(s)...
13:37:36.974 [main] INFO prs.Main$:218 - Error status set to pull request(s)
13:37:36.974 [main] INFO prs.Main$:224 - Closing async HTTP client
END RequestId: 8ae7eeea-5d97-11e7-8d69-ffaf80c8cde6
REPORT RequestId: 8ae7eeea-5d97-11e7-8d69-ffaf80c8cde6	Duration: 99287.03 ms	
Billed Duration: 99300 ms Memory Size: 384 MB	Max Memory Used: 199 MB

Our git repo is not that large, so this is suspect.

Perhaps, there should be a way to report how much space is left on the device before running the command by using java.io.File and outputting it to the log.

Discriminate pull request events

Not every pull request event from GitHub is created equal. Some are relevant to the mergeability of pull requests and some are not. For instance, editing the title or description of the pull request will initiate an event from GitHub. This is a useful event to some, but not for us. It should not initiate another merge process. There are no new commits to analyze, so it seems like a waste of resources to initiate a new integration.

If a label is added to a PR or someone requests a code review, then it should also be ignored.
GitHub's API has an action field for describing the types of PR actions:

  • assigned
  • unassigned
  • review_requested
  • review_request_removed
  • labeled
  • unlabeled
  • opened
  • edited
  • closed
  • reopened

It's not clear how to understand if the commits have changed from the above.

However, one benefit of this defect is that it does offer a manner to initiate the merge process again. This might be useful if there was a defect in this merging application, or there was a transient error (network issue, failure to retrieve pull request information or Git commits, and so on). So this may be a feature and not a bug.

Create git tag after merging

  • Objective: After pushing integration branch, add a tag to preserve the merge commit.
  • Presently, pushing integration branch overwrites and the merge was lost.
  • Rationale: Be able to track the mainline development with the branch development over time.
  • Safety: This could create a lot of tags and build a lot of commit references that won't be garbage collected for client users and the git server.
  • Configuration: Enable or disable?
  • Configuration: Configurable tag naming convention?

Push to separate repo

  • Objective: Push integration branch to a separate repository, rather than the same repository the base branch and PRs are located.
  • Presently, pushing integration branch can only be done to the same repository.
  • Rationale: This process should not have git access to the base repo. GitHub doesn't support it with private repos, but this follows the principle of least privilege. Further, automated integration work shouldn't interfere with the commit activities of the main repository. This function in AWS Lambda, will ignore push events from itself, but it is orthogonal to the usual git activity of the repo that is bound to have unnecessary consequences.
  • Safety: If the separate repo doesn't exist?
  • Configuration: Support pushing to same repo and separate repo?

Trigger on PushEvent

  • Objective: A continuous integration merge should be initiated by push events.
  • Presently, a continuous merge is only done on pull request events.
  • Rationale: if someone pushes commits to master outside of the GitHub pull request facilities, the "mergeability" needs to be recalculated.
  • Safety: The push event needs to cross-checked with the repository and master branch configured in the application config file.
  • Safety: Extra safety needs to be made to make sure that an SNS loop doesn't occur between pushing an integration branch which has the same name as the master branch. This is paranoid programming, but probably worth adding.
  • Configuration: Push events are already set to notify Amazon SNS by default, so there is no need to configure additional GitHub hooks, unlike how they have to be enabled for pull request events.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.