You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2017/10/17 11:00:25 UTC

Prototype of building github pull requests with Jenkins

Hi,

In order to validate that we are able to validate pull requests without
nagging infra I added experimental pull request validation to the sling
site repo.

The results are visible in the jenkins job [1] and in an example pull
request [2].

The Jenkins job is multi-branch pipeline and it's using a personal
access token under my account to communicate with Github. That's why my
face is next to the check, but once we are migrated we can request a
technical user from infra for this.

Robert

[1]: https://builds.apache.org/view/S-Z/view/Sling/job/sling-site/
[2]: https://github.com/apache/sling-site/pull/3

Re: Prototype of building github pull requests with Jenkins

Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2017-10-17 at 13:15 +0200, Konrad Windszus wrote:
> Great, thanks for that. Is it possible to directly expose the last
> build result in the Github PR though? I guess the according Jenkins
> Plugin should support that Ootb.

The result is exposed, but for merged pull requests it's a bit hidden.
In https://github.com/apache/sling-site/pull/3 click the 'View details'
button to expose the checks, including the Jenkins one.

In https://github.com/apache/sling-site/pull/2, which is not merged
yet, you will see a 'Checks' container at the bottom, including one
which says 'All checks have passed'. Click on 'Show all checks' to see
the Jenkins status.

Thanks,

Robert

> 
> Konrad
> 
> > Am 17.10.2017 um 13:00 schrieb Robert Munteanu <ro...@apache.org>
> > :
> > 
> > Hi,
> > 
> > In order to validate that we are able to validate pull requests
> > without
> > nagging infra I added experimental pull request validation to the
> > sling
> > site repo.
> > 
> > The results are visible in the jenkins job [1] and in an example
> > pull
> > request [2].
> > 
> > The Jenkins job is multi-branch pipeline and it's using a personal
> > access token under my account to communicate with Github. That's
> > why my
> > face is next to the check, but once we are migrated we can request
> > a
> > technical user from infra for this.
> > 
> > Robert
> > 
> > [1]: https://builds.apache.org/view/S-Z/view/Sling/job/sling-site/
> > [2]: https://github.com/apache/sling-site/pull/3
> 
> 


Re: Prototype of building github pull requests with Jenkins

Posted by Konrad Windszus <ko...@gmx.de>.
Great, thanks for that. Is it possible to directly expose the last build result in the Github PR though? I guess the according Jenkins Plugin should support that Ootb.

Konrad

> Am 17.10.2017 um 13:00 schrieb Robert Munteanu <ro...@apache.org>:
> 
> Hi,
> 
> In order to validate that we are able to validate pull requests without
> nagging infra I added experimental pull request validation to the sling
> site repo.
> 
> The results are visible in the jenkins job [1] and in an example pull
> request [2].
> 
> The Jenkins job is multi-branch pipeline and it's using a personal
> access token under my account to communicate with Github. That's why my
> face is next to the check, but once we are migrated we can request a
> technical user from infra for this.
> 
> Robert
> 
> [1]: https://builds.apache.org/view/S-Z/view/Sling/job/sling-site/
> [2]: https://github.com/apache/sling-site/pull/3


Re: Prototype of building github pull requests with Jenkins

Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2017-10-17 at 12:28 +0100, Ian Boston wrote:
> Hi,
> 
> On 17 October 2017 at 12:12, Robert Munteanu <ro...@apache.org>
> wrote:
> 
> > On Tue, 2017-10-17 at 12:08 +0100, Ian Boston wrote:
> > > Hi,
> > > Could travis be used ?
> > > 
> > > https://github.com/apache/sling/blob/trunk/.travis.yml
> > > 
> > > I dont think that need personal access tokens or  a special
> > > technical
> > > uses
> > > as it uses OAuth.
> > > 
> > > From memory the main problem with Travis + Sling is a) the size
> > > of
> > > the log
> > > file (fixed for Sling see yml file) and b) the time taken to
> > > build.
> > > Other
> > > than that it works well for small repos that build fast.
> > 
> > Travis requires administrative access to Github, which we don't
> > have.
> > 
> 
> https://travis-ci.org/apache/sling/builds/288988140?utm_source=github
> _status&utm_medium=notification
> 
> It seems to be active and working on apache/sling trunk
> I don't remember having administrative access to GitHub when making
> that
> work, but I guess perhaps, Infra had already enabled it.

Apparently it was me asking for it :-) I have a short memory [1]

> Enabling once per repo might be more attractive to Infra than having
> to
> manage 380+ special users, or perhaps thats the same thing.

We should be able to work with one 'sling-bot' special user for our
Jenkins needs. Or just stick with a committer as a special user.

> 
> > We would need to ask infra to do this, and since they do it
> > manually I
> > don't think it will be too high on their priority list.
> > 
> > Are we missing features from Travis or is it just the ease of
> > configuration?
> > 
> 
> Ease of configuration (once you get past its output limits)
> Good integration with GitHub, especially pull requests.
> Doesn't consume Apache resources. (I assume)
> 
> I've used both on other projects and generally found Travis less
> hassle
> than Jenkins, but thats only my experience.
> This has been especially true where I wanted to do a little more PR
> validation than a simple build.

I think Jenkins pipeline builds are a lot more flexible that 'classic'
freestyle of maven builds. I am not a big fan, but they do allow more
exotic scenarios.

Pull request integration is there with Jenkins as well.

As for Apache resources, the ASF currently pays for Travis credits
IIUC, see [2],[3],[4] so either way we're consuming something.

Anyway, bottom line is that our goal should be 'CI feedback on pull
requests', not 'Use Jenkins to validate pull requests'. I did this to
make sure we are not making an unwise move in migrating to Github with
280 repos and then finding out we can't easily add validation to pull
requests.

I am open to either tool and we should definitely evaluate after the
git migration has settled down.

We should definitely start with "what do we want to validate on a CI"
and find out the best tool. One example that would be more interesting
to set up is building and testing a bundle and the deploying it in the
current Sling launchpad and running the integration tests.

Thanks,

Robert

[1]: https://issues.apache.org/jira/browse/INFRA-6643?jql=project%20%3D
%20INFRA%20AND%20text%20~%20travis%20%20AND%20text%20~%20sling
[2]: https://issues.apache.org/jira/browse/INFRA-11121
[3]: https://issues.apache.org/jira/browse/INFRA-13634
[4]: https://blogs.apache.org/infra/entry/apache_gains_additional_travi
s_ci

Re: Prototype of building github pull requests with Jenkins

Posted by Ian Boston <ie...@tfd.co.uk>.
Hi,

On 17 October 2017 at 12:12, Robert Munteanu <ro...@apache.org> wrote:

> On Tue, 2017-10-17 at 12:08 +0100, Ian Boston wrote:
> > Hi,
> > Could travis be used ?
> >
> > https://github.com/apache/sling/blob/trunk/.travis.yml
> >
> > I dont think that need personal access tokens or  a special technical
> > uses
> > as it uses OAuth.
> >
> > From memory the main problem with Travis + Sling is a) the size of
> > the log
> > file (fixed for Sling see yml file) and b) the time taken to build.
> > Other
> > than that it works well for small repos that build fast.
>
> Travis requires administrative access to Github, which we don't have.
>

https://travis-ci.org/apache/sling/builds/288988140?utm_source=github_status&utm_medium=notification

It seems to be active and working on apache/sling trunk
I don't remember having administrative access to GitHub when making that
work, but I guess perhaps, Infra had already enabled it.
Enabling once per repo might be more attractive to Infra than having to
manage 380+ special users, or perhaps thats the same thing.



> We would need to ask infra to do this, and since they do it manually I
> don't think it will be too high on their priority list.
>
> Are we missing features from Travis or is it just the ease of
> configuration?
>

Ease of configuration (once you get past its output limits)
Good integration with GitHub, especially pull requests.
Doesn't consume Apache resources. (I assume)

I've used both on other projects and generally found Travis less hassle
than Jenkins, but thats only my experience.
This has been especially true where I wanted to do a little more PR
validation than a simple build.

Best Regards
Ian



>
> Thanks,
>
> Robert
>

Re: Prototype of building github pull requests with Jenkins

Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2017-10-17 at 12:08 +0100, Ian Boston wrote:
> Hi,
> Could travis be used ?
> 
> https://github.com/apache/sling/blob/trunk/.travis.yml
> 
> I dont think that need personal access tokens or  a special technical
> uses
> as it uses OAuth.
> 
> From memory the main problem with Travis + Sling is a) the size of
> the log
> file (fixed for Sling see yml file) and b) the time taken to build.
> Other
> than that it works well for small repos that build fast.

Travis requires administrative access to Github, which we don't have.
We would need to ask infra to do this, and since they do it manually I
don't think it will be too high on their priority list.

Are we missing features from Travis or is it just the ease of
configuration?

Thanks,

Robert

Re: Prototype of building github pull requests with Jenkins

Posted by Ian Boston <ie...@tfd.co.uk>.
Hi,
Could travis be used ?

https://github.com/apache/sling/blob/trunk/.travis.yml

I dont think that need personal access tokens or  a special technical uses
as it uses OAuth.

From memory the main problem with Travis + Sling is a) the size of the log
file (fixed for Sling see yml file) and b) the time taken to build. Other
than that it works well for small repos that build fast.
Best Regards
Ian


On 17 October 2017 at 12:00, Robert Munteanu <ro...@apache.org> wrote:

> Hi,
>
> In order to validate that we are able to validate pull requests without
> nagging infra I added experimental pull request validation to the sling
> site repo.
>
> The results are visible in the jenkins job [1] and in an example pull
> request [2].
>
> The Jenkins job is multi-branch pipeline and it's using a personal
> access token under my account to communicate with Github. That's why my
> face is next to the check, but once we are migrated we can request a
> technical user from infra for this.
>
> Robert
>
> [1]: https://builds.apache.org/view/S-Z/view/Sling/job/sling-site/
> [2]: https://github.com/apache/sling-site/pull/3
>