Status-react: Make it easier for all contributors to use CI tools (jenkins)

Created on 30 Nov 2017 · 19Comments · Source: status-im/status-react

User Story

As an external contributor I want some CI to give me feedback in PR if build was successful or not. I either want Jenkins to build my PR and deliver it much like Travis-CI or CircleCI does so that I can easily see if my submission passes all the necessary tests etc., or we should move over to one of the others to see if we can improve a bunch of processes and handle some sensitive info in ENV variables in the CI instead.

Description

Type: Feature

Summary: Currently it is very hard for external contributors to see if their changes pass the CI build as this integration is only available on our closed slack. Furthermore, we need manually to log in to Jenkins and trigger builds from external people, which is not very automated. We should change this by either switching tools, or finding a neat way to integrate Jenkins more closely with GH.

Expected behavior

Should be as easy as possible for external contributors to get feedback in PR if their build was successful or not.

Actual behavior

Jenkins integration currently only available in team slack.

Solution

Summary: Either find a neat way to integrate Jenkins and GH and then think about how to automate external builds in Jenkins, or move over to another CI tool.

Let the debates begin 😉

Source

andytudhope

Most helpful comment

@Alonski Yes we already have such behavior but it publishes result in an internal slack. What would be great is to have it published to GH too (and share build details at the same time).
This way everyone could see the result of the build.

See our current Jenkins config here

jeluard on 1 Dec 2017

👍2

All 19 comments

I think moving to Travis-CI makes sense to me as it seems like a lot of OSS projects use it and it supports a number of build matrices. It seems easier to work with from a setup standpoint as well. Jenkins feels like older clunkier software to me (this isn't a reason to switch though, just my personal bias).

I think out of the box it will support building forked repos, and we could fix Slack notification as well on builds while in there.

Discovery would be easier on a more open service as well–being able to find the builds and where they live.

I'd be passionate to take this on if it's something we want to explore and see if it's possible. I like setting up CI builds.

dbalatero on 30 Nov 2017

I also recommend moving to Travis which is free for OSS as @dbalatero said.
I can also help with this.
Can I get access to the Jenkins tool so that I can remodel it for Travis?

Alonski on 1 Dec 2017

What problem would moving away from Jenkins solve for us? (assuming Jenkins is available for everyone)

Jenkins offers us great flexibility (integration with external tools with slack) and we can control its scalability (especially macOSX builds are well known to be slow on TravisCI).
Ultimately Jenkins interactions will be automated so no one has to look at it.

jeluard on 1 Dec 2017

Maybe Jenkins can be setup to build every pull request and comment if it succeeds or fails? I am not as familiar with Jenkins but can look into it

Alonski on 1 Dec 2017

See our current Jenkins config here

jeluard on 1 Dec 2017

👍2

I'll try playing around with it this week. Hopefully I'll be able to get it working in my own branch

Alonski on 1 Dec 2017

If builds for Mac are slow on Travis that's a great reason to not switch.
Ultimately what I want as a non-core-team member is to see every commit
build status in Github via integration, and to be able to click through to
a URL and see exactly what failed. Other than that I'm good.

Someone with admin rights to Github/Jenkins will likely have to set this up
though.

On Fri, Dec 1, 2017 at 1:55 AM Alon Bukai notifications@github.com wrote:

I'll try playing around with it this week. Hopefully I'll be able to get
it working in my own branch

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/status-im/status-react/issues/2566#issuecomment-348452131,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADoJf5hZpk-BdxoEtVkzdhoqe_i3R8jks5s780cgaJpZM4QxQVj
.

dbalatero on 1 Dec 2017

@Alonski see here: https://jenkins.io/solutions/github

Most CI solutions I've seen hook into Github's API, vs posting a comment. Using an API hook would be nicer integration, if possible.

Also I think Jenkins should be publicly open, at least as a read-only URL. That way everyone sees the same view of CI.

dbalatero on 7 Dec 2017

I wanted to check in and see what the status is on this and/or if there is an open PR to track this work? Thanks!

dbalatero on 20 Dec 2017

Hi @dbalatero! I thought you were on holiday 😉 So, our new devops guy @v2nek is working on this, and last I heard there may be a OAuth solution to allowing some external contributors access to Jenkins. Though I also think that moving over to yarn with @oskarth is maybe more pressing right now.

andytudhope on 21 Dec 2017

Sounds good, I'll jump back on that yarn PR. I'm back as of yesterday!

dbalatero on 21 Dec 2017

🎉1

@dbalatero Welcome back! Our new devops guy is looking into GH auth or so at https://github.com/status-im/status-cluster/issues/14 (private repo unfortunately)

oskarth on 21 Dec 2017

Hi all, is there an update / anyone currently working on this?

eskp on 21 Jun 2018

Not really if I'm honest. @oskarth @jakubgs is this still something we need?

andytudhope on 21 Jun 2018

This has already been resolved. There is now anonymous read-only access enabled to Jenkins Build logs.
Example:
https://jenkins.status.im/blue/organizations/jenkins/status-react%2Fpull%20requests/detail/PR-4919/13/pipeline
I'm gonna close this issue in a day or few if this is enough.