Project

General

Profile

Feature #9741

Feature #9614: Automated builds: complete phase two

New jobs in Jenkins should be built immediately

Added by bertagaz over 4 years ago. Updated over 4 years ago.

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

0%

Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
No
Affected tool:

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.


Related issues

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

History

#1 Updated by bertagaz over 4 years ago

  • Parent task set to #9614

#2 Updated by intrigeri over 4 years ago

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 over 4 years ago

  • 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 over 1 year ago

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

Also available in: Atom PDF