modules/updateserver/files/sitescripts - Issue 5071748311547904: Issue 1094 - Generate update manifests on the update server

Side by Side Diff: modules/updateserver/files/sitescripts

Issue 5071748311547904: Issue 1094 - Generate update manifests on the update server (Closed)

Patch Set: Reduced duplication Created July 25, 2014, 7:17 a.m.

Left:
Right:

Use n/p to move between diff chunks; N/P to move between comments.

Jump to:

View unified diff | Download patch

OLD	NEW
(Empty)
	1 [extensions]

	2 hg_root=/var/lib/adblockplus
	Wladimir Palant 2014/07/25 09:50:11 We usually keep the repositories under /opt (see d We usually keep the repositories under /opt (see discourse, notificationserver and sitescripts) - I guess we should do it here as well for consistency. Felix Dahlke 2014/07/25 10:31:15 Based on the file system hierarchy standard, /var/ Show quoted text On 2014/07/25 09:50:11, Wladimir Palant wrote: > We usually keep the repositories under /opt (see discourse, notificationserver > and sitescripts) - I guess we should do it here as well for consistency. Based on the file system hierarchy standard, /var/lib is the best place for application specific changing files. /opt is for applications that don't comply with the FHS basically.
	3 abp_repository=%(hg_root)s/adblockplus

	4 abpsafari_repository=%(hg_root)s/adblockpluschrome

	5 abpsafari_type=safari

	6 abpsafari_key=%(hg_root)s/adblockplussafari.pem
	Wladimir Palant 2014/07/25 09:50:11 Ouch, keeping that key on the update server only f Ouch, keeping that key on the update server only for the sake of extracting the extension ID sucks. We need to find a better solution for this. I guess that a long-term solution will be a build server to produce releases. That one could store the relevant metadata for each release in some location where the update server can look it up. This will also make it unnecessary to sync the repositories on the update server. Felix Dahlke 2014/07/25 10:31:15 Yes, I believe that's the best approach. For now w Show quoted text On 2014/07/25 09:50:11, Wladimir Palant wrote: > Ouch, keeping that key on the update server only for the sake of extracting the > extension ID sucks. We need to find a better solution for this. > > I guess that a long-term solution will be a build server to produce releases. > That one could store the relevant metadata for each release in some location > where the update server can look it up. This will also make it unnecessary to > sync the repositories on the update server. Yes, I believe that's the best approach. For now we can live with this how it is I suppose.
	7 abpandroid_repository=%(hg_root)s/adblockplusandroid

	8 abpandroid_type=android

	9 ehh_repository=%(hg_root)s/elemhidehelper

	10 watcher_repository=%(hg_root)s/abpwatcher

	11 customization_repository=%(hg_root)s/abpcustomization

	12 urlfixer_repository=%(hg_root)s/urlfixer

	13 downloadsrepo=%(hg_root)s/downloads

	14 downloadsurl=https://downloads.adblockplus.org/

	15 web_root=/var/www/update

	16 geckoUpdateManifestPath=%(web_root)s/adblockplus/update.rdf
	Wladimir Palant 2014/07/25 09:50:11 That's a rather misleading path given that this fi That's a rather misleading path given that this file will be used for multiple extensions including URL Fixer. Maybe /firefox/update.rdf? We could also create individual update manifests for the extensions, that would require more changes to the scripts however. Felix Dahlke 2014/07/25 10:31:15 Went even further and called the thing "gecko". Bu Show quoted text On 2014/07/25 09:50:11, Wladimir Palant wrote: > That's a rather misleading path given that this file will be used for multiple > extensions including URL Fixer. Maybe /firefox/update.rdf? > > We could also create individual update manifests for the extensions, that would > require more changes to the scripts however. Went even further and called the thing "gecko". But yeah, I guess it makes sense to split this up, filed a follow-up for that: https://issues.adblockplus.org/ticket/1142 Wladimir Palant 2014/07/25 11:11:02 Note that splitting up is better done before we re Show quoted text On 2014/07/25 10:31:15, Felix H. Dahlke wrote: > Went even further and called the thing "gecko". But yeah, I guess it makes sense > to split this up, filed a follow-up for that: > > https://issues.adblockplus.org/ticket/1142 Note that splitting up is better done before we redirect the old update manifests, this will get pretty messy otherwise. Felix Dahlke 2014/07/25 14:17:56 Messy how? We don't need redirects for the individ Show quoted text On 2014/07/25 11:11:02, Wladimir Palant wrote: > On 2014/07/25 10:31:15, Felix H. Dahlke wrote: > > Went even further and called the thing "gecko". But yeah, I guess it makes > sense > > to split this up, filed a follow-up for that: > > > > https://issues.adblockplus.org/ticket/1142 > > Note that splitting up is better done before we redirect the old update > manifests, this will get pretty messy otherwise. Messy how? We don't need redirects for the individual update manifests if those are going to the proper update server to begin with.
	17 geckoUpdateManifest=extensions/template/update.rdf

	18 safariUpdateManifestPath=%(web_root)s/adblockplussafari/updates.plist

	19 safariUpdateManifest=extensions/template/updates.plist

	20 androidUpdateManifestPath=%(web_root)s/adblockplusandroid/androidupdates.xml
	Wladimir Palant 2014/07/25 09:50:11 updates.xml please - it was only called androidupd updates.xml please - it was only called androidupdates.xml on the main server because of another file called updates.xml. Felix Dahlke 2014/07/25 10:31:15 Done. Show quoted text On 2014/07/25 09:50:11, Wladimir Palant wrote: > updates.xml please - it was only called androidupdates.xml on the main server > because of another file called updates.xml. Done.
	21 androidUpdateManifest=extensions/template/androidupdates.xml

OLD	NEW

« no previous file with comments | « modules/private-stub/files/adblockplussafari.pem ('k') | modules/updateserver/manifests/init.pp » ('j') | modules/updateserver/manifests/init.pp » ('J')