Opened on 09/19/2014 at 12:59:53 PM
Last modified on 12/21/2017 at 11:28:41 AM
#1418 new change
[abp] Generate devbuild update manifests on the update servers
| Reported by: | fhd | Assignee: | |
|---|---|---|---|
| Priority: | Unknown | Milestone: | |
| Module: | Infrastructure | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Platform: | Unknown | |
| Ready: | no | Confidential: | no |
| Tester: | Unknown | Verified working: | no |
| Review URL(s): | |||
Description
Background
Generating update manifests for devbuilds is currently happening right after we build those. We should generate and host these update manifests on the update servers - next to the stable ones.
What to change
There are multiple ways of achieving this. What I think would be the cleanest (but not easiest) way is to publish devbuilds by pushing them to a repository (e.g. downloads) as opposed to pulling them directly from the build server.
Then we could generate the update manifests the same way we generate the stable ones: By looking at what's in the downloads repository. All the build server would have to do is push the new version into the repository.
Attachments (0)
Change History (3)
comment:1 Changed on 09/19/2014 at 01:03:27 PM by fhd
- Cc trev added
comment:2 Changed on 12/22/2016 at 11:14:36 PM by ferris
- Summary changed from Generate devbuild update manifests on the update servers to [abp] Generate devbuild update manifests on the update servers
- Tester set to Unknown
comment:3 Changed on 12/21/2017 at 11:28:41 AM by fhd
- Cc trev removed
Note: See
TracTickets for help on using
tickets.
I deliberately didn't set this to ready, nor did I set a priority - up to you.
I'm not sure if it's practical to manage binaries that change multiple times a day in a Mercurial repository as I suggested, but IMO we do need some kind of repository for build artifacts - and if it's just a plain file server. Once we have that for the devbuilds, we can move devbuild generation to a dedicated build server.