Re: [jdt-core-dev] Builds seem to be getting aborted -> tidy up?

["Markus Keller" <markus_keller@xxxxxxxxxx>]

I've increased the "Max # of builds
to keep" in the Gerrit job to 20 (like for platform.ui).
It looks like someone else already increased
the timeout to "elastic" (200% of last successful build or 180
minutes).

I agree that not every commit is worth
running a Gerrit build. I guess one problem is about Git/EGit/Gerrit setup
and maybe people don't know they can also push to refs/heads/master of
a Gerrit URL.

My preferred config is this:

[remote "origin"]

        url = "">
        fetch = +refs/heads/*:refs/remotes/origin/*
        fetch = refs/notes/*:refs/notes/*
        pushurl = ssh://mkeller@xxxxxxxxxxxxxxx:29418/jdt/eclipse.jdt.core.git
[branch "master"]
        remote = origin
        merge = refs/heads/master
        rebase = true

That way, I fetch things quickly via the git: protocol, and direct pushes to upstream don't open a Gerrit change.

When I want to push to Gerrit, I click "Add Change-Id", commit, and then use "Push to Gerrit..." in the Git Repositories view. Unfortunately, that command is not available in recent versions of EGit, unless you add something like this to the config, see bug 501102:

[remote "crapForEGitBug501102"]
        url = "">
        fetch = +refs/heads/*:refs/remotes/origin/*
        fetch = refs/notes/*:refs/notes/*
        push = HEAD:refs/for/master

Another nice feature of that setup is that when I push a change with Change-Id to upstream, Gerrit automatically marks the Gerrit change as merged, so I don't even have to fiddle with the Gerrit web UI. The only problem with that is if I amended or rebased the commit, pushing to Gerrit creates a new patch set, which triggers another build that I kill manually when I know it's not relevant.

Markus




From:        Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
To:        jdt-core-dev@xxxxxxxxxxx
Date:        2017-01-07 15:19
Subject:        Re: [jdt-core-dev] Builds seem to be getting aborted -> tidy up?
Sent by:        jdt-core-dev-bounces@xxxxxxxxxxx

---

In this context, several of us are having difficulties picking up
the logs of any failed builds, because jobs are getting deleted
after ten builds. We could discuss increasing the number of
jobs retained, but perhaps the following would be more effective:

Can we try to avoid unnecessary builds in the hudson list of
recent builds?

- No-risk commits:
  (I know, literally this doesn't exist :)
  Why run a build just for adding a copyright header?

- If you trigger a flood of builds, it would be nice to delete
  any builds, whose logs are no longer needed.

I sometimes trigger a build in the evening and would like to
inspect the result on the next day. If failure logs are already
gone when I look this is a waste of resources :)

what do you think?
Stephan


Am 01/06/2017 um 04:07 PM schrieb Stefan Xenos:
> In the past few days, I've noticed that most of my gerrit builds seem to be getting aborted. For example:
>
> https://git.eclipse.org/r/#/c/88110/
>
> Is someone aborting them intentionally, or should I bring this up with the webmaster as a bug in the build system?
>
>   - Stefan
>
>
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
>

_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev