On Thu, Aug 14, 2014 at 2:53 PM, Alex Harui <[email protected]> wrote:
> > > On 8/14/14 2:24 PM, "OmPrakash Muppirala" <[email protected]> wrote: > > >My understanding is that you are manually updating the installer config > >with a new md5 value each time the artifact changes, is that correct? By > >letting the Jenkins job compute the checksum for the artifact, you dont > >have to manually change the config file everytime. > > > >You can still employ your technique of looking at last modified date. My > >suggestion does not require you to change that logic. > > > >Yes, it is a one time change to the Installer itself, but after that > >change > >you dont have to wait for the MD5 check to break, hopefully someone > >reports > >it us and we having to change the installer config. > I still don't get it. The installer.xml that shipped with Flex 4.13.0 is > looking up the md5 in sdk-installer-config-4.0.xml. I don't see any way > to prevent it from doing so. > You can modify the Installer to load the jenkins based md5 url and use that to verify the downloaded file. For example, today, the Apache Flex SDK is downloaded from a mirror, but the MD5 is downloaded from dist.apache.org/path_to_flex_artifact/artifactname.MD5. The same way, we can download the Flash artifact from the Adobe server and the MD5 value from our trusted Jenkins url. > > The job currently runs once a day, but we could run it hourly. I think we > could try to have the job update the sdk-installer-config-4.0.xml > automatically if we're brave enough to let it do so. But the main reason > someone found the issue was that the job did not run because the jenkins > slave broke down. However, even if we do automatic hourly updates we'll > be open to someone not being able to install for 59 minutes if we have bad > timing. > In that case, we can simply ask the user to retry after an hour. > > -Alex > >
