Feature #5898
Update Jenkins jobs on Git push
100%
Description
Run jenkins-jobs update /etc/jenkins_jobs/jobs/ when the Jenkins jobs repository gets an update.
Subtasks
History
#1 Updated by Tails 2013-07-18 10:39:40
- Parent task set to
Feature #5324
#2 Updated by bertagaz 2013-07-22 11:50:08
- Assignee set to bertagaz
- Starter set to No
#3 Updated by BitingBird 2014-06-09 10:23:17
- Subject changed from update Jenkins jobs on Git push to Update Jenkins jobs on Git push
#4 Updated by intrigeri 2014-08-02 16:40:26
- Target version set to Sustainability_M1
(Subtask of a ticket flagged for 2.0.)
#5 Updated by bertagaz 2014-12-10 21:44:35
For now our jenkins-jobs recipes are hosted on git.t.b.o, and this gitolite instance is whilelisting hooks we can run on our repos (thanks to them if they ever read).
OTHO automating build on pushes from git.t.b.o to our automated build infra sounds like a bad idea, giving a lot of unnecessary power to a machine on another one. And makes no sense if our jenkins instance host is down.
So I propose our jenkins jobs repo being hosted on our self-administered gitolite instance (no offense), which btw is at the moment hosted on the same machine than our jenkins instance. It would be authoritative on the git.t.b.o one.
It will also help to tie up the commit bit on that git repo, which would be at least granted by only one gitolite instance.
#6 Updated by intrigeri 2014-12-11 17:05:57
> So I propose our jenkins jobs repo being hosted on our self-administered gitolite instance (no offense), which btw is at the moment hosted on the same machine than our jenkins instance.
ACK.
#7 Updated by intrigeri 2015-01-09 17:21:58
- Target version changed from Sustainability_M1 to Tails_1.4
#8 Updated by bertagaz 2015-01-10 15:17:10
- Target version changed from Tails_1.4 to Tails_1.3
#10 Updated by bertagaz 2015-02-25 09:50:56
- Status changed from Confirmed to Resolved
- Assignee deleted (
bertagaz) - % Done changed from 0 to 100
#11 Updated by intrigeri 2015-05-29 11:33:45
- blocks #8668 added