Community
Participate
Working Groups
Due to recent infrastructure changes and restrictions, our Orbit builds no longer automatically upload to download server. Will investigate.
what I know so far ... just to "reveal all" ... the 'orbitBuild' ID actually runs the builds, and in the past, to automatically upload those to "download1" I'd do some fancy-but-not-so-secure stuff with SSH to use by 'david_williams' ID to do the automatic upload to 'download1' (which, last year was given to me by webmasters, as the only SSH permitted download server). The webmasters now claim no knowledge of 'download1' :) ... and even if they did remember it, it is the just the type of SSH access they (we?) are trying to reduce. So ... My plan is change our process so that our "committer builds" stay on the build machine, and once verified, and desired to be promoted, me (or, other committer) can login to build machine and "promote" to download machine, using their normal committer ID. For example, promote from /shared/orbit/committers/... to .../downloads/tools/orbit/download/drops/... This is fairly similar to what we current do, ... except we "promote" from .../downloads/tools/orbit/committers to .../downloads/tools/orbit/download/drops/... The desire and ability to do this anyway has been tracked a long time in bug 230061 and, as said there, most of this is already in place, just needs to some finishing touches and testing ... a day or less of real work ... which means may take "rest of the week" in elapsed time to finalize. If someone needs a build promote to "downloads" before then, let me know and I can certainly promote one without the fancy scripts ... but, I will begin on the fancy scripts soon. (The scripts just "automatically find latest build and copy to the right place ... to avoid typos, etc.). This will change our "committers downloads URL" but, we can leave a "forwarding address" in old location, update wikis, etc. In other words, this infrastructure change about SSH access will just "force" us to make improvements we wanted to do anyway.
I've done one step, just to get the builds to stop trying to upload to 'downloads' and leave builds on build.eclipse.org. Sent note to orbit-dev giving warning of new committers URL, though it is not finished yet. Also found one place in our wiki http://wiki.eclipse.org/Orbit/Promotion%2C_Release%2C_and_Retention_Policies#Continuous_Builds that refered to the "old" URL, so went ahead and changed it to the new one, http://build.eclipse.org/orbit/committers/ even though new one does not look very pretty at the moment. I'll continue working on a summary page for build machine URL. Then I'll work on 'promote' script (since, we can always promote without a script, if required).
I think I'm done for now. Warm up builds left on build machine, until we want to promote one to downloads server. Hence, the promote procedure/scripts have changed ... no longer use the 'declare.sh' script on downloads server, but instead use the promote.sh script on build server. I have written up details in http://wiki.eclipse.org/Orbit/Builds#How_to_declare_or_promote_a_build Another change: now (since code was mostly in place) we can "send a message" to orbit-dev list, when a build is promoted ... just as an automatic notification to community when a new build is promoted to downloads. Another change: again, just because the code to do so was mostly in place, as part of the promote script, we "process artifacts" in making the final build repository on downloads server, so there will be .pack.gz files available at the http:// repository. Hopefully will make some target definitions quicker? Note, though, these are not added to the archived (zipped) version of the build repository and there are no plans to (I think it would be inappropriate to). Feel free to educate me if that's not the case.
