[Seaside] Build Process
Locked
 
|
Hi there,
Having watched the build process for the first time, it looks like there are some complicated steps involved. I have read the MakeRelease document on the Wiki, and I wondered if there's room for further improvements/automation ? If there's one issue that particularly captured my attention, it was the fact that we had to stop further commits to the repository during the build. I'd love to hear your thought about this. Cheers, Avi. _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Seaside] Build Process
|
|
2011/3/5 Avi Shefi <[hidden email]>:
> Hi there, > Having watched the build process for the first time, it looks like there are > some complicated steps involved. > I have read the MakeRelease document on the Wiki, and I wondered if there's > room for further improvements/automation ? The functional tests are not automated. > If there's one issue that particularly captured my attention, it was the > fact that we had to stop further commits to the repository during the build. > I'd love to hear your thought about this. I just make commits that should not go into the release to a local file repository. Works fine. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Seaside] Build Process
|
|
Functional tests cannot be automated because they are output-driven. One could test them using Selenium or WebTester, however things like HTML5 functional tests are not possible because they rely on browsers implementations.
Regarding local files - it's not what bothers me. I can live with local files, even though I believe that dangling files are a recipe for information loss. Here are two key points which derive from this: - Why not create a configuration for the Hudson build server to fetch specific Monticello packages, by versions? This would eliminate the need to not commit to Monticello while building a version. - How can we automate the process of testing Seaside via the different platforms? If we have a uniform build process, maybe this can encourage other dialects to maintain their ports to Seaside? - Is the OneClick distribution automated, or is it built manually? We can make the build process less involved. Avi. On Sat, Mar 5, 2011 at 7:16 PM, Philippe Marschall <[hidden email]> wrote: 2011/3/5 Avi Shefi <[hidden email]>: _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by littleSmalltalker
the commits are suspended because the final release image/changes comes from the Hudson build, but since hudson doesn't use Metacello, the two can easily get out of synch.
If there was a hudson build dedicated to building from the Seaside3.0 metacallo configuration and if the image/changes for the release came from that build, then suspending commits wouldn't be necessary ... You picked a doozy of a build to look at tho:) Not only did I run into a series of bugs while just loading and testing for Pharo, but I had a number of GemStone-related issues pop up during the porting of the changes to GemStone, not to mention a number of non-Seaside-related issues to boot. In the past, there were few update/test errors and the port to GemStone was quick. Dale On Mar 5, 2011, at 8:34 AM, Avi Shefi wrote: Hi there, Having watched the build process for the first time, it looks like there are some complicated steps involved. I have read the MakeRelease document on the Wiki, and I wondered if there's room for further improvements/automation ? If there's one issue that particularly captured my attention, it was the fact that we had to stop further commits to the repository during the build. I'd love to hear your thought about this. Cheers, Avi. <ATT00001..txt> _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by littleSmalltalker
More often than not the integration of changes from the Pharo version of Seaside to GemStone involves manual intervention by a developer to resolve. So automation on that from would require my attention anyway ...
I have been threatening to convert the functional tests to automated tests, but have just not had the cycles to do so ... it would be very useful. I _am_ spending time on the MetacelloBrowser ... when that tool is ready, the Seaside developers could use the MetacelloBrowser to update the configs for Grease and Seaside rather than waiting me to find time to do it ... Oh and let's see, I think there should be a hudson build for just Grease since one of the issues this time around would have been exposed by a Grease only build ... using a configuration to load Grease would have exposed the problem as well, but I know that Grease is being used in other projects besides Seaside, so independent testing there would be useful... Dale On Mar 5, 2011, at 9:27 AM, Avi Shefi wrote: Functional tests cannot be automated because they are output-driven. One could test them using Selenium or WebTester, however things like HTML5 functional tests are not possible because they rely on browsers implementations. Regarding local files - it's not what bothers me. I can live with local files, even though I believe that dangling files are a recipe for information loss. Here are two key points which derive from this: - Why not create a configuration for the Hudson build server to fetch specific Monticello packages, by versions? This would eliminate the need to not commit to Monticello while building a version. - How can we automate the process of testing Seaside via the different platforms? If we have a uniform build process, maybe this can encourage other dialects to maintain their ports to Seaside? - Is the OneClick distribution automated, or is it built manually? We can make the build process less involved. Avi. On Sat, Mar 5, 2011 at 7:16 PM, Philippe Marschall <[hidden email]<mailto:[hidden email]>> wrote: 2011/3/5 Avi Shefi <[hidden email]<mailto:[hidden email]>>: > Hi there, > Having watched the build process for the first time, it looks like there are > some complicated steps involved. > I have read the MakeRelease document on the Wiki, and I wondered if there's > room for further improvements/automation ? The functional tests are not automated. > If there's one issue that particularly captured my attention, it was the > fact that we had to stop further commits to the repository during the build. > I'd love to hear your thought about this. I just make commits that should not go into the release to a local file repository. Works fine. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email]<mailto:[hidden email]> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev <ATT00001..txt> _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Seaside] Build Process
|
|
In reply to this post by littleSmalltalker
2011/3/5 Avi Shefi <[hidden email]>:
> Functional tests cannot be automated because they are output-driven. One > could test them using Selenium or WebTester, however things like HTML5 > functional tests are not possible because they rely on browsers > implementations. Which is the same when running the test manually. That doesn't mean we should automate the other 95% that matter. > Regarding local files - it's not what bothers me. I can live with local > files, even though I believe that dangling files are a recipe for > information loss. Here are two key points which derive from this: > - Why not create a configuration for the Hudson build server to fetch > specific Monticello packages, by versions? This would eliminate the need to > not commit to Monticello while building a version. Again, I don't see this as an issue. > - How can we automate the process of testing Seaside via the different > platforms? If we have a uniform build process, maybe this can encourage > other dialects to maintain their ports to Seaside? How and when other platforms make releases doesn't affect us. > - Is the OneClick distribution automated, or is it built manually? Automated, why? > We can make the build process less involved. Having it done several times I really feel that manually running the functional tests is the biggest issue. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On Sun, Mar 6, 2011 at 2:19 PM, Philippe Marschall
<[hidden email]> wrote: > 2011/3/5 Avi Shefi <[hidden email]>: >> We can make the build process less involved. > > Having it done several times I really feel that manually running the > functional tests is the biggest issue. Agreed. Everything else is now automated enough that it's not too much hassle. The functional tests are a big pain... Which is not to say they should be got rid of, because they are useful examples to exercise specific functionality when you are developing and want to try things out. But it would be nice to to rely on them to verify builds. Julian _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Seaside] Build Process
|
|
So we have two issues:
1) Functional tests - can we, or can't we automate these? even if a large portion can be automated, how do you think this should be done? 2) Should we have a Grease-only build? (Dale's suggestion) Regarding suspending the commits until a release - this works only because we're a small community :) I would definitely go for an automated build system which can handle both: (a) taking the latest package versions and doing nightly builds; and (b) defining a set of packages (or a Metacello configuration) for a release, and building it regardless of new commits (whether through a dedicated Hudson Seaside build, or some other mechanism). Another issue: Dale, Do we build/update/run a new release under each and every dialect manually? If it's manual, then maybe there's room for a script that fetches a Metacello configuration and runs Seaside tests against all dialects? or possibly a few dialect-specific scripts that automate this? Avi. On Sun, Mar 6, 2011 at 6:48 PM, Julian Fitzell <[hidden email]> wrote: On Sun, Mar 6, 2011 at 2:19 PM, Philippe Marschall _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On Mar 6, 2011, at 9:33 AM, Avi Shefi wrote: So we have two issues: 1) Functional tests - can we, or can't we automate these? even if a large portion can be automated, how do you think this should be done? 2) Should we have a Grease-only build? (Dale's suggestion) Regarding suspending the commits until a release - this works only because we're a small community :) I would definitely go for an automated build system which can handle both: (a) taking the latest package versions and doing nightly builds; and (b) defining a set of packages (or a Metacello configuration) for a release, and building it regardless of new commits (whether through a dedicated Hudson Seaside build, or some other mechanism). Another issue: Dale, Do we build/update/run a new release under each and every dialect manually? If it's manual, then maybe there's room for a script that fetches a Metacello configuration and runs Seaside tests against all dialects? or possibly a few dialect-specific scripts that automate this? If someone created and maintained a hudson server that loaded the seaside configs for squeak I wouldn't have to do the manual builds/tests:) As I've mentioned before, the GemStone builds require manual merges and the other platforms don't use Monticello let alone Metacello:) Frankly I am still doing the metacello stuff manually so that I can experience the pain and improve metacello itself, as long as I keep learning from the experience I don't mind doing it manually ... but if there were more automation for building on the Squeak releases and the old Pharo releases, I wouldn't complain:) Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Seaside] Build Process
|
|
re dedicated Hudson server - not needed. I thought the current server could be configured to have an artifact set under which you define a build based on specific versions of packages.
re Squeak & Pharo automation - sounds good, probably requires a Hudson plugin to make it happen. Considering the responses I guess this is irrelevant at the present moment. Avi. On Sun, Mar 6, 2011 at 7:48 PM, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On 7 March 2011 12:26, Avi Shefi <[hidden email]> wrote:
> re dedicated Hudson server - not needed. I thought the current server could > be configured to have an artifact set under which you define a build based > on specific versions of packages. > > re Squeak & Pharo automation - sounds good, probably requires a Hudson > plugin to make it happen. No, no plugin required. Just a line of Smalltalk code to trigger Metacello. Previously we didn't have Metacello builds, because ... - Metacello wouldn't allow us to load the latest code. And this was one of the main goals: To always have up-to-date builds with the very latest code, so that we know when something broke. This seems to be fixed nowadays. - Metacello builds were really slow compared to the traditional ones (which are already slow). Again this made it less useful to have a quick feedback loop. I don't know if this is fixed nowadays? It would be really easy to setup a different build (even if it was slower) that uses Monticello and that would only be triggered when the configuration changes. Does that make sense? What would be the code to trigger Metacello? What repository would need to be observed for changes? Doesn't Pharo already do that? Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On 03/07/2011 09:26 AM, Lukas Renggli wrote:
> On 7 March 2011 12:26, Avi Shefi<[hidden email]> wrote: >> re dedicated Hudson server - not needed. I thought the current server could >> be configured to have an artifact set under which you define a build based >> on specific versions of packages. >> >> re Squeak& Pharo automation - sounds good, probably requires a Hudson >> plugin to make it happen. > > No, no plugin required. Just a line of Smalltalk code to trigger > Metacello. Previously we didn't have Metacello builds, because ... > > - Metacello wouldn't allow us to load the latest code. And this was > one of the main goals: To always have up-to-date builds with the very > latest code, so that we know when something broke. This seems to be > fixed nowadays. Right: (ConfigurationOfSeaside30 project version: #bleedingEdge) load will load the latest packages of Seaside as well as selected dependent projects: Kom and Grease. > > - Metacello builds were really slow compared to the traditional ones > (which are already slow). Again this made it less useful to have a > quick feedback loop. I don't know if this is fixed nowadays? Metacello is faster than it used to be, but there's still room for improvement and room to improve:) > > It would be really easy to setup a different build (even if it was > slower) that uses Monticello and that would only be triggered when the > configuration changes. Does that make sense? What would be the code to > trigger Metacello? What repository would need to be observed for > changes? Doesn't Pharo already do that? You are already doing the #bleedingEdge builds, so that would only be useful from the perspective that Metacello will flush out dependency bugs that the current build process doesn't uncover. It would be nice if there were continuous development builds for all of the supported Pharo versions (whatever the list is) and adding Squeak builds would be nice, too. The most useful from my perspective would be a #stable build. The stable build could be used to produce the Pharo release artifacts: image, changes, on-clicks based on the configurations...Right now there is potential for discrepancies between the configurations and the release artifacts....With a hudson build using the confg there'd be no discrepancies. The build would be triggered by a change to ConfigurationOfGrease or ConfigurationOfSeaside30. If you have some way of tracking state, then you would only trigger a build if the value of the #stable version changed: (ConfigurationOfSeaside30 project version: #stable) ~= previousStableVersion Pharo builds the stable Seaside release on Pharo1.2 only which AFIAK isn't supported by Seaside30 yet... Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
> You are already doing the #bleedingEdge builds, so that would only be useful
> from the perspective that Metacello will flush out dependency bugs that the > current build process doesn't uncover. It would be nice if there were > continuous development builds for all of the supported Pharo versions > (whatever the list is) and adding Squeak builds would be nice, too. It is the responsibility of the respective stakeholders to keep their ports up-to-date. Different Hudson/Jenkins instances can interoperate with each other, so we could combine the results of all build servers at a central location. However, I am not willing to maintain builds for platforms I don't care about. > The most useful from my perspective would be a #stable build. The stable > build could be used to produce the Pharo release artifacts: image, changes, > on-clicks based on the configurations...Right now there is potential for > discrepancies between the configurations and the release artifacts....With a > hudson build using the confg there'd be no discrepancies. I think it would make sense to have a parallel "stable" Metacello based build that updates whenever the Metacello configuration changes. > Pharo builds the stable Seaside release on Pharo1.2 only which AFIAK isn't > supported by Seaside30 yet... I don't think Pharo 1.2 stable is out yet, or did I miss something? My Jenkins instance uses http://www.pharo-project.org/pharo-download/stable which still points to Pharo 1.1. As soon as this changes we will likely have to fix a few things. Also note that Pharo itself has several builds (that include Seaside) that are based on their development images: https://pharo-ic.lille.inria.fr/hudson/view/Pharo-Clients/ Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On 03/08/2011 10:42 AM, Lukas Renggli wrote:
>> You are already doing the #bleedingEdge builds, so that would only be useful >> from the perspective that Metacello will flush out dependency bugs that the >> current build process doesn't uncover. It would be nice if there were >> continuous development builds for all of the supported Pharo versions >> (whatever the list is) and adding Squeak builds would be nice, too. > > It is the responsibility of the respective stakeholders to keep their > ports up-to-date. Different Hudson/Jenkins instances can interoperate > with each other, so we could combine the results of all build servers > at a central location. However, I am not willing to maintain builds > for platforms I don't care about. That's fine...it _was_ worth mentioning though:) > >> The most useful from my perspective would be a #stable build. The stable >> build could be used to produce the Pharo release artifacts: image, changes, >> on-clicks based on the configurations...Right now there is potential for >> discrepancies between the configurations and the release artifacts....With a >> hudson build using the confg there'd be no discrepancies. > > I think it would make sense to have a parallel "stable" Metacello > based build that updates whenever the Metacello configuration changes. That would be excellent! > >> Pharo builds the stable Seaside release on Pharo1.2 only which AFIAK isn't >> supported by Seaside30 yet... > > I don't think Pharo 1.2 stable is out yet, or did I miss something? I was referring the the #stable version of Seaside30, not Pharo, sorry. > > My Jenkins instance uses > http://www.pharo-project.org/pharo-download/stable which still points > to Pharo 1.1. As soon as this changes we will likely have to fix a few > things. > > Also note that Pharo itself has several builds (that include Seaside) > that are based on their development images: > https://pharo-ic.lille.inria.fr/hudson/view/Pharo-Clients/ Right and those are all built against Pharo 1.2 and Seaside30 isn't supported on Pharo 1.2 yet ... Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Seaside] Build Process
|
|
Just looked at the Jenkins (previously Hudson) build server, and saw that there are separate tabs for Seaside 2.8 and Seaside 3.0.
Does this mean that we have separate builds for each one? Avi. On Tue, Mar 8, 2011 at 10:03 PM, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
Yes. We probably stop to produce 2.8 builds soon, as Magritte and Pier
(and most other open-source projects) are sucessfully running on Seaside 3.0. Also there has been no new changes in the 2.8 branch lately. Lukas On Thursday, 10 March 2011, Avi Shefi <[hidden email]> wrote: > Just looked at the Jenkins (previously Hudson) build server, and saw that there are separate tabs for Seaside 2.8 and Seaside 3.0. > Does this mean that we have separate builds for each one? > > Avi. > > On Tue, Mar 8, 2011 at 10:03 PM, Dale Henrichs <[hidden email]> wrote: > On 03/08/2011 10:42 AM, Lukas Renggli wrote: > > > You are already doing the #bleedingEdge builds, so that would only be useful > from the perspective that Metacello will flush out dependency bugs that the > current build process doesn't uncover. It would be nice if there were > continuous development builds for all of the supported Pharo versions > (whatever the list is) and adding Squeak builds would be nice, too. > > > It is the responsibility of the respective stakeholders to keep their > ports up-to-date. Different Hudson/Jenkins instances can interoperate > with each other, so we could combine the results of all build servers > at a central location. However, I am not willing to maintain builds > for platforms I don't care about. > > > > That's fine...it _was_ worth mentioning though:) > > > > > The most useful from my perspective would be a #stable build. The stable > build could be used to produce the Pharo release artifacts: image, changes, > on-clicks based on the configurations...Right now there is potential for > discrepancies between the configurations and the release artifacts....With a > hudson build using the confg there'd be no discrepancies. > > > I think it would make sense to have a parallel "stable" Metacello > based build that updates whenever the Metacello configuration changes. > > > > That would be excellent! > > > > > Pharo builds the stable Seaside release on Pharo1.2 only which AFIAK isn't > supported by Seaside30 yet... > > > I don't think Pharo 1.2 stable is out yet, or did I miss something? > > > > I was referring the the #stable version of Seaside30, not Pharo, sorry. > > > > My Jenkins instance uses > http://www.pharo-project.org/pharo-download/stable which still points > to Pharo 1.1. As soon as this changes we will likely have to fix a few > things. > > Also note that Pharo itself has several builds (that include Seaside) > that are based on their development images: > https://pharo-ic.lille.inria.fr/hudson/view/Pharo-Clients/ > > > > Right and those are all built against Pharo 1.2 and Seaside30 isn't supported on Pharo 1.2 yet ... > > > Dale > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
«
Return to Seaside Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |