Feature #9741

New jobs in Jenkins should be built immediately

Added by bertagaz 2015-07-14 06:22:54 . Updated 2015-07-15 06:32:59 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Continuous Integration
Target version:
Tails_1.5
Start date:
2015-07-14
Due date:
% Done:

0%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

Description

When someone pushes a new branch, its job is now added in Jenkins, but new jobs are not build immediately. A build is then triggered either by a timer or by a new push.

So if a developer created a new branch, worked on it and then only pushed her first commit, her changes won’t get tested directly.

To workaround that, a developer can still push her new branch right after branching from the original branch, which would add the job, then work on it and push, so that she has her fist changes on the branch built immediately. This should at least be documented in the contribute section of the website.

But it might be good to find a way to have new jobs built as soon as they are added to Jenkins.

Subtasks

Related issues

Related to Tails - Feature #16059: Improve UX for scheduling builds for newly pushed branches on the CI Resolved 2018-10-16

History

#1 Updated by bertagaz 2015-07-14 06:23:21

#2 Updated by intrigeri 2015-07-14 14:16:17

> When someone pushes a new branch, its job is now added in Jenkins, but new jobs are not build immediately. A build is then triggered either by a timer or by a new push.

(Just my 2 cents here, no strong opinion.)

I’m personally fine with the current behaviour:

  • sometimes we push branches that were just forked from stable or devel, without any change, just to see the corresponding APT suite created; in this case, building an ISO on Jenkins would be a waste of resources;
  • a developer who’s currently actively working on a branch presumably has built and tested it before pushing, so it’s no big deal if next automatic build waits up to 24 hours.

But I could live with something quicker as well, which has its own advantages, e.g. the potential to make the dev/push/review/merge loop faster.

#3 Updated by bertagaz 2015-07-15 06:32:59

  • Status changed from New to Rejected
  • Assignee deleted (bertagaz)
  • QA Check deleted (Dev Needed)

bertagaz wrote:

> > To workaround that, a developer can still push her new branch right after branching from the original branch, which would add the job, then work on it and push, so that she has her fist changes on the branch built immediately.

Note that this is not True: when one branch a new dev branch and push it immediately, the job isn’t added as this new branch doesn’t contain new unmerged commits.

intrigeri wrote:
> > When someone pushes a new branch, its job is now added in Jenkins, but new jobs are not build immediately. A build is then triggered either by a timer or by a new push.
>
> (Just my 2 cents here, no strong opinion.)
>
> I’m personally fine with the current behaviour:
>
> * sometimes we push branches that were just forked from stable or devel, without any change, just to see the corresponding APT suite created; in this case, building an ISO on Jenkins would be a waste of resources;
> * a developer who’s currently actively working on a branch presumably has built and tested it before pushing, so it’s no big deal if next automatic build waits up to 24 hours.
>
> But I could live with something quicker as well, which has its own advantages, e.g. the potential to make the dev/push/review/merge loop faster.

Ok, makes sense and doesn’t seem that much needed. Less work!

#4 Updated by intrigeri 2018-12-02 18:00:01

  • related to Feature #16059: Improve UX for scheduling builds for newly pushed branches on the CI added