Is there a tonel:// format for repos?
Hi - I converted my project to tonel, and am looking to hook it up to my gitlab pipeline, and for older projects I had a run.st <http://run.st/> script that did: Metacello new baseline: 'WillowPagerDuty'; repository: âfiletree://../src'; load. I get a not found error when I run that, is there a new repo type for tonel eg? Metacello new baseline: 'WillowPagerDuty'; repository: 'tonel://../src'; load. Or is this the PR Esteban was working on earlier this month so that filetree can support tonel? If so, it would be very good to get this support as it makes it much easier to write generic scripts to run in CI projects without having to reference branch names to build things (as its simply the source in you git directory that you want to build locally ) Tim
Hmmm - will have to try that again - I seemed to get an error - maybe this is just a Pharo 7 thing? It had previously been simpler and more reliable to just run a simple gitlab ci pipeline - but yeah maybe I should reconsider that...
On 14 May 2018, at 16:59, Peter Uhnák <i.uhnak@gmail.com> wrote:
Metacello new baseline: 'WillowPagerDuty'; repository: 'tonel://../src <>'; load.
This should work.
You can also use SmalltalkCI instead of doing everything by hand.
Peter
Tim Mackinnon wrote
to just run a simple gitlab ci pipeline
Can't you just use `gitlab://` and Iceberg/Metacello integration? IIUC it "just works" for tones, with or without Smalltalk CI (but I haven't ported to tonel yet, so take FWIW) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Peter - thanks for getting me to retry it - it turns out that tonel:// is correct, and I had misread the error message - which was actually due to me misnaming the baselineOf project suffix. To your point Sean - if using a CI server - if you use GitHub or GitLab:// prefixes - you need ssh key installed on our server which then becomes a real pain - so sticking to https (and public repos) and any source that is checked it with your project on build - is a big simplification. Iâ in the process of weeding out some rogue GitHub:// baselines as they fail and then cause my loading image to bomb out (I suspect Peter has weeded all of this out in SmalltalkCI). Iâm forging on - but may take another look at SmalltalkCI - the trouble is, I really donât like Travis (I find it really hard to use - and never understood why it was successful, and equally Jenkins is a mess). I quite like the model of Gitlabâs one stop shop - and I was interested in simplifying it from what I did for PharoLambda - but its been a bit more painful than I had expected. Tim
On 14 May 2018, at 18:09, Tim Mackinnon <tim@testit.works> wrote:
Hmmm - will have to try that again - I seemed to get an error - maybe this is just a Pharo 7 thing?
It had previously been simpler and more reliable to just run a simple gitlab ci pipeline - but yeah maybe I should reconsider that...
On 14 May 2018, at 16:59, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
Metacello new baseline: 'WillowPagerDuty'; repository: 'tonel://../src <>'; load.
This should work.
You can also use SmalltalkCI instead of doing everything by hand.
Peter
Tim Mackinnon wrote
may take another look at SmalltalkCI - the trouble is, I really donât like Travis⦠I quite like the model of Gitlabâs one stop shop
I use SmalltalkCI on Gitlab (https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Sean - thanks for mentioning that - I tried it ages ago and didnât get on well with it on Travs. But I donât understand how it works on Gitlab - and the project readme.md seems to assume you understand how its approaching the problem (which possibly has changed over the years). Looking at your url - how is that running a project that you have in a different repo? Is there some web hook that causes it to then trigger a build cycle? I can see you edited a BaselineOfGitLabCI and added a BabyPhexample <https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci/commit/d59ba3788aa86bde3...> - which seems a bit inside out to me - but Iâm hanging in there (so do you add other projects in this same file?). I also donât understand the pipeline model - there seems to be just one pipeline (and gitlab has great pipeline support)? And then - when it all builds successfully - how does it deploy (hence my pipeline question). Iâm lost - but curious, as maybe I can save time on what Iâm doing (writing more apps vs pissing around with missing infrastructure). Tim
On 14 May 2018, at 22:38, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:
Tim Mackinnon wrote
may take another look at SmalltalkCI - the trouble is, I really donât like Travis⦠I quite like the model of Gitlabâs one stop shop
I use SmalltalkCI on Gitlab (https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci <https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci>)
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html>
Hi Tim, It should be relatively straightforward to use smalltalkCI on Gitlab CI. All you have to take care of is to ensure the Linux container has all Pharo dependencies [1] installed correctly. If you append smalltalkCI's `bin` directory to your $PATH, you can simply call `smalltalkci -s Pharo-6.0` in your project's root directory to test against Pharo-6.0. Hope this helps. And if you work out a simple and generic way of using smalltalkCI on Gitlab, please feel free to open a PR against smalltalkCI and contribute a template :) Best, Fabio [1] https://github.com/travis-ci/travis-build/blob/51ebd738f537a82874b03cb964eca... On Tue, May 15, 2018 at 12:40 AM Tim Mackinnon <tim@testit.works> wrote:
Hi Sean - thanks for mentioning that - I tried it ages ago and didnât get on well with it on Travs. But I donât understand how it works on Gitlab - and the project readme.md seems to assume you understand how its approaching the problem (which possibly has changed over the years).
Looking at your url - how is that running a project that you have in a different repo? Is there some web hook that causes it to then trigger a build cycle? I can see you edited a BaselineOfGitLabCI and added a BabyPhexample <https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci/commit/d59ba3788aa86bde3...> - which seems a bit inside out to me - but Iâm hanging in there (so do you add other projects in this same file?).
I also donât understand the pipeline model - there seems to be just one pipeline (and gitlab has great pipeline support)?
And then - when it all builds successfully - how does it deploy (hence my pipeline question).
Iâm lost - but curious, as maybe I can save time on what Iâm doing (writing more apps vs pissing around with missing infrastructure).
Tim
On 14 May 2018, at 22:38, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tim Mackinnon wrote
may take another look at SmalltalkCI - the trouble is, I really donât like Travis⦠I quite like the model of Gitlabâs one stop shop
I use SmalltalkCI on Gitlab (https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci)
----- Cheers, Sean
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Thanks Fabio - it sounds like Sean already has figured something out - but I havenât fully grokâd how it hangs together. From your description, it sounds like you expect SmalltalkCI to be like a submodule of your project - and you can then invoke it from your normal projects build script? However peeking at what Sean pointed at - it seemed like he expected you to intermingle your project with the SmalltalkCI one - so Iâm not really clear on how he uses it. It sounds like all the right pieces are there - just not quite sure what the concept is - particularly given that Gitlab Pipelines already is a CI with the concept of jobs - just not Smalltalk ones. At its best - how does SmalltalkCI function - I never quite understood the pipeline when checked years ago. Tim
On 15 May 2018, at 09:09, Fabio Niephaus <lists@fniephaus.com> wrote:
Hi Tim,
It should be relatively straightforward to use smalltalkCI on Gitlab CI. All you have to take care of is to ensure the Linux container has all Pharo dependencies [1] installed correctly. If you append smalltalkCI's `bin` directory to your $PATH, you can simply call `smalltalkci -s Pharo-6.0` in your project's root directory to test against Pharo-6.0.
Hope this helps. And if you work out a simple and generic way of using smalltalkCI on Gitlab, please feel free to open a PR against smalltalkCI and contribute a template :)
Best, Fabio
[1] https://github.com/travis-ci/travis-build/blob/51ebd738f537a82874b03cb964eca... <https://github.com/travis-ci/travis-build/blob/51ebd738f537a82874b03cb964eca...>
On Tue, May 15, 2018 at 12:40 AM Tim Mackinnon <tim@testit.works> wrote: Hi Sean - thanks for mentioning that - I tried it ages ago and didnât get on well with it on Travs. But I donât understand how it works on Gitlab - and the project readme.md seems to assume you understand how its approaching the problem (which possibly has changed over the years).
Looking at your url - how is that running a project that you have in a different repo? Is there some web hook that causes it to then trigger a build cycle? I can see you edited a BaselineOfGitLabCI and added a BabyPhexample <https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci/commit/d59ba3788aa86bde3...> - which seems a bit inside out to me - but Iâm hanging in there (so do you add other projects in this same file?).
I also donât understand the pipeline model - there seems to be just one pipeline (and gitlab has great pipeline support)?
And then - when it all builds successfully - how does it deploy (hence my pipeline question).
Iâm lost - but curious, as maybe I can save time on what Iâm doing (writing more apps vs pissing around with missing infrastructure).
Tim
On 14 May 2018, at 22:38, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:
Tim Mackinnon wrote
may take another look at SmalltalkCI - the trouble is, I really donât like Travis⦠I quite like the model of Gitlabâs one stop shop
I use SmalltalkCI on Gitlab (https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci <https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci>)
----- Cheers, Sean
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html>
Hi Tim, On Tue, May 15, 2018 at 11:56 AM Tim Mackinnon <tim@testit.works> wrote:
Thanks Fabio - it sounds like Sean already has figured something out - but I havenât fully grokâd how it hangs together. From your description, it sounds like you expect SmalltalkCI to be like a submodule of your project - and you can then invoke it from your normal projects build script? However peeking at what Sean pointed at - it seemed like he expected you to intermingle your project with the SmalltalkCI one - so Iâm not really clear on how he uses it.
It sounds like all the right pieces are there - just not quite sure what the concept is - particularly given that Gitlab Pipelines already is a CI with the concept of jobs - just not Smalltalk ones.
At its best - how does SmalltalkCI function - I never quite understood the pipeline when checked years ago.
smalltalkCI is not intended to be a Git submodule at all. It's simply some program you can download, extract, and then run by calling `bin/smalltalkci`. And it happens to look for .smalltalk.ston configuration files. It's also deeply integrated with TravisCI, so the setup is done in background. I've had a look at Sean's project and think I understood how things work on GitLab CI and Docker. I want common use cases to be as simple as possible, so I've created a minimal .gitlab-ci.yml template [1] for smalltalkCI (assuming you have your project already set up with a baseline and a .smalltalk.ston). Could you please give it a try? Best, Fabio [1] https://gist.github.com/fniephaus/b95c4ed15abd8c4305277f51fbe21fee
Tim
On 15 May 2018, at 09:09, Fabio Niephaus <lists@fniephaus.com> wrote:
Hi Tim,
It should be relatively straightforward to use smalltalkCI on Gitlab CI. All you have to take care of is to ensure the Linux container has all Pharo dependencies [1] installed correctly. If you append smalltalkCI's `bin` directory to your $PATH, you can simply call `smalltalkci -s Pharo-6.0` in your project's root directory to test against Pharo-6.0.
Hope this helps. And if you work out a simple and generic way of using smalltalkCI on Gitlab, please feel free to open a PR against smalltalkCI and contribute a template :)
Best, Fabio
[1] https://github.com/travis-ci/travis-build/blob/51ebd738f537a82874b03cb964eca...
On Tue, May 15, 2018 at 12:40 AM Tim Mackinnon <tim@testit.works> wrote:
Hi Sean - thanks for mentioning that - I tried it ages ago and didnât get on well with it on Travs. But I donât understand how it works on Gitlab - and the project readme.md seems to assume you understand how its approaching the problem (which possibly has changed over the years).
Looking at your url - how is that running a project that you have in a different repo? Is there some web hook that causes it to then trigger a build cycle? I can see you edited a BaselineOfGitLabCI and added a BabyPhexample <https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci/commit/d59ba3788aa86bde3...> - which seems a bit inside out to me - but Iâm hanging in there (so do you add other projects in this same file?).
I also donât understand the pipeline model - there seems to be just one pipeline (and gitlab has great pipeline support)?
And then - when it all builds successfully - how does it deploy (hence my pipeline question).
Iâm lost - but curious, as maybe I can save time on what Iâm doing (writing more apps vs pissing around with missing infrastructure).
Tim
On 14 May 2018, at 22:38, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tim Mackinnon wrote
may take another look at SmalltalkCI - the trouble is, I really donât like Travis⦠I quite like the model of Gitlabâs one stop shop
I use SmalltalkCI on Gitlab (https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci)
----- Cheers, Sean
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Tim Mackinnon wrote
But I donât understand how it works on Gitlab
The gitlab-smalltalk-ci project performs three roles: 1. The glue which connects Gitlab and smalltalkCI. As a bonus, it does all the necessary in-container work to setup SSH for private Gitlab projects, so you'd just have to create/enable the deploy key in the Gitlab web UI. 2. A Pharo library to create/modify CI artifacts like configuration files. This let's you write Smalltalk like this `GitLabCIConfiguration new smalltalkImageTemplateFor: 'Pharo-6.1'` instead of being forced to remember and write: ```yaml .pharo61_template: &pharo61 variables: SMALLTALK_IMAGE: "Pharo-6.1" ``` 3. An example to adapt for your own project, since it eats its own dog food and is handling its own CI. Also, note that the initial setup is simplified from smalltalkCI because it uses a Docker image preloaded with all the Pharo dependencies. 1. First, you would create a `.gitlab-ci.yml`. I'm guessing you already know that it is the equivalent to Travis' `.travis.yml`, which is the main hook that the CI system picks up to run whatever you tell it to. If you read it, you will see that it's main job is to install the glue scripts and run the downloaded scripts/build.sh. The bottom ~half is the workaround for matrix builds (for Pharo 6 & 7) in GitlabCI, which are not directly supported. 2. Next, create a `.smalltalk.ston`. This is the main config hook for smalltalkCI. I added some links to the docs in the README. That's really it I think. All this has been tested extensively with real projects, but only on Pharo 6/7 and Ubuntu 32 bit. PRs welcome and feel free to ask more questions! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Sean - it certainly sounds like its worth a poke. Have you written anything else up about it - or is this the âuser manualâ for now? Presumable a lot of the below could go in the readme.md for the project itself. So to get started with it - is the intent that you fork it so you can customise the settings? OR do you make it a submodule of your existing project so that you can access the scripts? As you want to trigger something when you checkin your smalltalk code - is it a trigger in that project that kicks off a separate SmalltalkCIGL project to then do its stuff, or do you just just include it in your current project so you can reference these scripts? This is the bit Iâm not understanding? Reading below - am I understanding that when you get your pipeline trigger, you use GitLabCIConfiguration to write out some config that you can then get SmalltalkCI to interpret with the assets that you have? Iâl have to go back and look again. Tim
On 15 May 2018, at 14:25, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tim Mackinnon wrote
But I donât understand how it works on Gitlab
The gitlab-smalltalk-ci project performs three roles: 1. The glue which connects Gitlab and smalltalkCI. As a bonus, it does all the necessary in-container work to setup SSH for private Gitlab projects, so you'd just have to create/enable the deploy key in the Gitlab web UI. 2. A Pharo library to create/modify CI artifacts like configuration files. This let's you write Smalltalk like this `GitLabCIConfiguration new smalltalkImageTemplateFor: 'Pharo-6.1'` instead of being forced to remember and write: ```yaml .pharo61_template: &pharo61 variables: SMALLTALK_IMAGE: "Pharo-6.1" ``` 3. An example to adapt for your own project, since it eats its own dog food and is handling its own CI.
Also, note that the initial setup is simplified from smalltalkCI because it uses a Docker image preloaded with all the Pharo dependencies.
1. First, you would create a `.gitlab-ci.yml`. I'm guessing you already know that it is the equivalent to Travis' `.travis.yml`, which is the main hook that the CI system picks up to run whatever you tell it to. If you read it, you will see that it's main job is to install the glue scripts and run the downloaded scripts/build.sh. The bottom ~half is the workaround for matrix builds (for Pharo 6 & 7) in GitlabCI, which are not directly supported. 2. Next, create a `.smalltalk.ston`. This is the main config hook for smalltalkCI. I added some links to the docs in the README.
That's really it I think. All this has been tested extensively with real projects, but only on Pharo 6/7 and Ubuntu 32 bit. PRs welcome and feel free to ask more questions!
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Tim Mackinnon wrote
Have you written anything else up about it - or is this the âuser manualâ for now?
The latter :) It was an itch I scratched because GL offers unlimited private projects and significant CI build time for free and then shared just in case others were struggling with the same thing, but I'm happy to answer questions and add to the docs. Tim Mackinnon wrote
Presumable a lot of the below could go in the readme.md for the project itself.
Already done! Tim Mackinnon wrote
So to get started with it
In your project's root folder, if you copy `.gitlab-ci.yml` verbatim and modify `.smalltalk.ston` as needed, it should start building your project on top of Pharo 6 & 7 on 32-bit Ubuntu LTS. The Smalltalk image versions can be changed to anything accepted by smalltalkCI, and I think to support other OS'es we'd just need to build alternate Docker images [1]. You would only need to fork gitlab-smalltalk-ci if you want to modify the internals of the library itself. If you just want to customize any of the scripts in ./scripts [2] on a per-project basis, you can just save overridden copies in ./scripts in your project. The library will not overwrite existing script files in that location. FYI I did not explore deploy steps yet. I was actually waiting to develop further because the next thing I want is separate build and test steps so one can immediately know whether the installation or testing failed, and it seemed that might be added to smalltalkCI in the near future. 1. There is also a related library which enables you to generate docker files from Pharo. See https://github.com/seandenigris/smalltalkCI/tree/docker/repository/Smalltalk... 2. https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci/tree/master/scripts ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Sean/Fabio - Iâm still mulling over which direction to jump. When experimenting with PharoLambda and a minimal image it was all very custom and so I just used GitLab ânativelyâ - and as you have noted - Gitlab has got a lot of built in CI stuff. Now my need has expanded to something a bit more normal - I was a bit caught out that the above didnât just work the same. As its turned out - what has been the hiccup has been not having a good stable Linux image to build on (Iâve now learned Docker to sort that bit out - and really must +++ the need to have some pharo.org <http://pharo.org/> docker containers just sitting there for people to use). The other issue has been what you have said - in a clean build environment you donât have ssh keys normally defined and and the use of Iceberg and projects using github:// (which needs them by default) causes quite a lot of pain (even if they arenât private repos). I mention this as Herby spotted it a while ago as he doesnât use GitHub - however he also spotted a solution that I donât think you are aware of (judging from your gitlab project) - in your preload script add the following: Iceberg enableMetacelloIntegration: true; remoteTypeSelector: #httpsUrl. This was the piece I was missing - and now my project is loading fine (in its fresh docker environment). You of course probably still have Private repos and in that case I think you still need the ssh keys sorted - but for a more general case I donât think its needed. This long path (which has usefully solidified lots of things for me) still leaves me unsure as to whether I personally need SmalltalkCI for simple single vendor projects (as when used in GitLab - its not really doing any CI - it seems more useful for muli-dialect building I think). Maybe you guys might set me straight on this⦠the reality is all you are really plugging into Gitlab is: pharo Pharo.image --no-default-preferences --save --quit st loadProject.st \ "{'$PROJECT_NAME'. '$PROJECT_API_KEY'}" 2>&1 | tee LoadProject.log And if you are also doing some testing a second invocation (ideally in a separate build stage) of: pharo Pharo.image --no-default-preferences --save --quit st testProject.st \ "{'$PROJECT_NAME'. '$PROJECT_API_KEY'}" 2>&1 | tee TestProject.log And with a good docker image it seems pretty straight forward. Possibly there are components in SmalltalkCI that could be extracted - maybe to interpret test results? Or I am wondering if its useful to pump stats into something like DataDog to track image size and test run times etc? Iâm still interested in both your thoughts though - and by no means is this a citicism of SmalltalkCI or Gitlab-Smalltalk-CI - both of which help the community (and me) immensely through providing great examples and knowledgable people in this stuff. Tim
On 16 May 2018, at 02:50, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tim Mackinnon wrote
Have you written anything else up about it - or is this the âuser manualâ for now?
The latter :) It was an itch I scratched because GL offers unlimited private projects and significant CI build time for free and then shared just in case others were struggling with the same thing, but I'm happy to answer questions and add to the docs.
Tim Mackinnon wrote
Presumable a lot of the below could go in the readme.md for the project itself.
Already done!
Tim Mackinnon wrote
So to get started with it
In your project's root folder, if you copy `.gitlab-ci.yml` verbatim and modify `.smalltalk.ston` as needed, it should start building your project on top of Pharo 6 & 7 on 32-bit Ubuntu LTS. The Smalltalk image versions can be changed to anything accepted by smalltalkCI, and I think to support other OS'es we'd just need to build alternate Docker images [1]. You would only need to fork gitlab-smalltalk-ci if you want to modify the internals of the library itself. If you just want to customize any of the scripts in ./scripts [2] on a per-project basis, you can just save overridden copies in ./scripts in your project. The library will not overwrite existing script files in that location.
FYI I did not explore deploy steps yet. I was actually waiting to develop further because the next thing I want is separate build and test steps so one can immediately know whether the installation or testing failed, and it seemed that might be added to smalltalkCI in the near future.
1. There is also a related library which enables you to generate docker files from Pharo. See https://github.com/seandenigris/smalltalkCI/tree/docker/repository/Smalltalk... 2. https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci/tree/master/scripts
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Tim Mackinnon wrote
the use of Iceberg and projects using github:// (which needs them by default) causes quite a lot of pain (even if they arenât private repos). ⦠Iceberg enableMetacelloIntegration: true; remoteTypeSelector: #httpsUrl.
This is part of my standard workflow and I didn't experience it as a pain point. It seems I uploaded my public GH key, but after that it "just worked". IIRC it seemed to automatically fallback to https when ssh failed, but it's been a while and I'm not in front of a pipeline. The first message is needed, especially to use `gitlab://` URLs, but I never used the second. Tim Mackinnon wrote
the reality is all you are really plugging into Gitlab is: â¦loadProject.st⦠testProject.st
I guess you could say that, except smalltalkCI also handles any needed setup, like Linux 32-bit libs (which I handle with Docker instead). Also, it saves you from having to construct the .st files in your example because: - there is a configuration model that allows you to specify the baseline name, target platforms, etc instead of manually writing load scripts - smalltalkCI remembers which tests it loaded and runs those automatically, so by default no extra work is needed to enable testing Tim Mackinnon wrote
by no means is this a citicismâ¦
All good :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Sean - I stand corrected, #remoteTypeSelector: doesnât seem to be needed (a case of getting all the other stuff right - and Docker is such a huge help for this). For SmalltalkCI the automatic Test side might win me over. Does it also spot load load failures (like Undeclared class) and do a nice test report? I just spotted Seaside isnât loading cleanly with my RegEx setup - but its crude. This has been very fruitful BTW , thanks Tim Sent from my iPhone Sent from my iPhone
On 16 May 2018, at 19:54, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tim Mackinnon wrote
the use of Iceberg and projects using github:// (which needs them by default) causes quite a lot of pain (even if they arenât private repos). ⦠Iceberg enableMetacelloIntegration: true; remoteTypeSelector: #httpsUrl.
This is part of my standard workflow and I didn't experience it as a pain point. It seems I uploaded my public GH key, but after that it "just worked". IIRC it seemed to automatically fallback to https when ssh failed, but it's been a while and I'm not in front of a pipeline. The first message is needed, especially to use `gitlab://` URLs, but I never used the second.
Tim Mackinnon wrote
the reality is all you are really plugging into Gitlab is: â¦loadProject.st⦠testProject.st
I guess you could say that, except smalltalkCI also handles any needed setup, like Linux 32-bit libs (which I handle with Docker instead). Also, it saves you from having to construct the .st files in your example because: - there is a configuration model that allows you to specify the baseline name, target platforms, etc instead of manually writing load scripts - smalltalkCI remembers which tests it loaded and runs those automatically, so by default no extra work is needed to enable testing
Tim Mackinnon wrote
by no means is this a citicismâ¦
All good :)
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Sean, Sorry, I just saw your response. Questions/comments are inline... On Tue, May 15, 2018 at 3:26 PM Sean P. DeNigris <sean@clipperadams.com> wrote:
Tim Mackinnon wrote
But I donât understand how it works on Gitlab
The gitlab-smalltalk-ci project performs three roles: 1. The glue which connects Gitlab and smalltalkCI. As a bonus, it does all the necessary in-container work to setup SSH for private Gitlab projects, so you'd just have to create/enable the deploy key in the Gitlab web UI.
This is only needed for private repos on GitLab, right?
2. A Pharo library to create/modify CI artifacts like configuration files. This let's you write Smalltalk like this `GitLabCIConfiguration new smalltalkImageTemplateFor: 'Pharo-6.1'` instead of being forced to remember and write: ```yaml .pharo61_template: &pharo61 variables: SMALLTALK_IMAGE: "Pharo-6.1" ```
This library needs to be used manually, right? Or is this somehow part of the build process?
3. An example to adapt for your own project, since it eats its own dog food and is handling its own CI.
Also, note that the initial setup is simplified from smalltalkCI because it uses a Docker image preloaded with all the Pharo dependencies.
1. First, you would create a `.gitlab-ci.yml`. I'm guessing you already know that it is the equivalent to Travis' `.travis.yml`, which is the main hook that the CI system picks up to run whatever you tell it to. If you read it, you will see that it's main job is to install the glue scripts and run the downloaded scripts/build.sh. The bottom ~half is the workaround for matrix builds (for Pharo 6 & 7) in GitlabCI, which are not directly supported. 2. Next, create a `.smalltalk.ston`. This is the main config hook for smalltalkCI. I added some links to the docs in the README.
That's really it I think. All this has been tested extensively with real projects, but only on Pharo 6/7 and Ubuntu 32 bit. PRs welcome and feel free to ask more questions!
Sorry for not being very responsive recently, I've been super busy. I think it'd be great if we could somehow merge your additions back into smalltalkCI's repo. It's much easier, especially for users, if everything is in one place. Also, I'd love to hear your feedback on the solution I suggested in my previous email. Any ideas how to make it better? Have a look at the launcher script for smalltalkCI [1] used in the Docker image. I'm sure we could at least add the private repo ssh-agent setup process in there as well. PRs welcome! :) Cheers, Fabio [1] https://github.com/hpi-swa/smalltalkCI/blob/docker/smalltalkci
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
fniephaus wrote
As a bonus, it does all
the necessary in-container work to setup SSH for private Gitlab projects, so you'd just have to create/enable the deploy key in the Gitlab web UI.
This is only needed for private repos on GitLab, right?
Correct. fniephaus wrote
This library needs to be used manually, right? Or is this somehow part of the build process?
The library is used to generate the artifacts (e.g. config files), which are then committed to be picked up by the CI. I assume that's what you meant by "manually"? fniephaus wrote
I think it'd be great if we could somehow merge your additions back into smalltalkCI's repo.
Definitely open to that. I got it "working" for my use cases and then paused. IIRC I did open a few issues in smalltalkCI related to this and Docker. fniephaus wrote
I'd love to hear your feedback on the solution I suggested in my previous email. Any ideas how to make it better?
Which one? fniephaus wrote
Have a look at the launcher script for smalltalkCI [1] used in the Docker image.
I will. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Wed, May 16, 2018 at 3:34 AM Sean P. DeNigris <sean@clipperadams.com> wrote:
fniephaus wrote
As a bonus, it does all
the necessary in-container work to setup SSH for private Gitlab projects, so you'd just have to create/enable the deploy key in the Gitlab web UI.
This is only needed for private repos on GitLab, right?
Correct.
fniephaus wrote
This library needs to be used manually, right? Or is this somehow part of the build process?
The library is used to generate the artifacts (e.g. config files), which are then committed to be picked up by the CI. I assume that's what you meant by "manually"?
Yes, that's what I meant. Up until now, templates have worked quite well, but I can also see why a library would be helpful at some point.
fniephaus wrote
I think it'd be great if we could somehow merge your additions back into smalltalkCI's repo.
Definitely open to that. I got it "working" for my use cases and then paused. IIRC I did open a few issues in smalltalkCI related to this and Docker.
Yes, you did. And I hope I have more time to work on smalltalkCI features soon...the list is getting longer and longer.
fniephaus wrote
I'd love to hear your feedback on the solution I suggested in my previous email. Any ideas how to make it better?
Which one?
This one: https://gist.github.com/fniephaus/b95c4ed15abd8c4305277f51fbe21fee
fniephaus wrote
Have a look at the launcher script for smalltalkCI [1] used in the Docker image.
I will.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Iâve created a new thread on Smalltalk CI - but back to tonel - having got my local project to start reading - its now failing when it then starts processing my BaselineOf and hits my willow dependency - which was initially things like: spec baseline: 'WillowBootstrap' with: [ spec repository: 'github://ba-st/Willow-Bootstrap:v8/source'; loads: #('Deployment') ]; import: 'WillowBootstrap'. The trouble being that the use of GitHub:// causes it to barf as it then wants ssh keys and crashes when trying to flip to https automatically. I figured I could just specify 'https://github <https://github/>.com/ba-st/Willow-Boostrap/tree/v8/sourceâ but this doesnât work either - as then I get a retry error: Fetched -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src Loaded -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src Loading baseline of BaselineOfPagerDuty...The method Integer>>#asBytesDescription called from ZnUtils class>>#signalProgress:total: has been deprecated. Please use #humanReadableSIByteSize instead ...RETRY->BaselineOfWillowBootstrap ...RETRY->BaselineOfWillowBootstrap ...FAILED->BaselineOfWillowBootstrap'Errors in script loaded from /builds/macta/WillowPagerDuty/build/loadProject.st' Could not resolve: BaselineOfWillowBootstrap [BaselineOfWillowBootstrap] in /builds/macta/WillowPagerDuty/build/pharo-local/package-cache https://github.com/ba-st/Willow-Bootstrap/tree/v8/source MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: Its very weird - and much harder than I was expecting it all to be (hence the renewed interest in Smalltalk CI). Saying this - what Iâm trying to do should be dead easy. Tim
On 14 May 2018, at 22:38, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tim Mackinnon wrote
may take another look at SmalltalkCI - the trouble is, I really donât like Travis⦠I quite like the model of Gitlabâs one stop shop
I use SmalltalkCI on Gitlab (https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci)
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hey! On Tue, May 15, 2018 at 12:46 AM, Tim Mackinnon <tim@testit.works> wrote:
Iâve created a new thread on Smalltalk CI - but back to tonel - having got my local project to start reading - its now failing when it then starts processing my BaselineOf and hits my willow dependency - which was initially things like:
spec baseline: 'WillowBootstrap' with: [ spec repository: 'github://ba-st/Willow-Bootstrap:v8/source'; loads: #('Deployment') ]; import: 'WillowBootstrap'.
The trouble being that the use of GitHub:// causes it to barf as it then wants ssh keys and crashes when trying to flip to https automatically.
Can you share the log of this? I'd like to know why https fails (as it shouldn't!).
I figured I could just specify 'https://github.com/ba-st/ Willow-Boostrap/tree/v8/sourceâ but this doesnât work either - as then I get a retry error:
Fetched -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/ WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src Loaded -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/ WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src Loading baseline of BaselineOfPagerDuty...The method Integer>>#asBytesDescription called from ZnUtils class>>#signalProgress:total: has been deprecated. Please use #humanReadableSIByteSize instead
...RETRY->BaselineOfWillowBootstrap ...RETRY->BaselineOfWillowBootstrap ...FAILED->BaselineOfWillowBootstrap'Errors in script loaded from /builds/macta/WillowPagerDuty/build/loadProject.st' Could not resolve: BaselineOfWillowBootstrap [BaselineOfWillowBootstrap] in /builds/macta/WillowPagerDuty/build/pharo-local/package-cache https://github.com/ba-st/Willow-Bootstrap/tree/v8/source MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>> retryingResolvePackageSpecReferences:gofer:
Its very weird - and much harder than I was expecting it all to be (hence the renewed interest in Smalltalk CI). Saying this - what Iâm trying to do should be dead easy.
Tim
On 14 May 2018, at 22:38, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tim Mackinnon wrote
may take another look at SmalltalkCI - the trouble is, I really donât like Travis⦠I quite like the model of Gitlabâs one stop shop
I use SmalltalkCI on Gitlab (https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci)
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
-- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
Hi - Iâll extract the log files when Iâm at my desk I can possibly make the pipeline public so you can better see it - and itâs a relatively simple app so maybe it can shed some light (although Iâm still not ruling out my own stupidity yet). Itâs a Pharo 6.1 64 bit image - download on build, applied to Ubuntu 17.10 (the same happens with 16.04). Tim The initial error is: Starting Load Script...
Configure Load caches... Loading Projects...
Fetched -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src Loaded -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src Loading baseline of BaselineOfPagerDuty... ...RETRY->BaselineOfWillowBootstrap ...RETRY->BaselineOfWillowBootstrap gofer repository error: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: ZnHttpUnsuccessful: 404 Not Found'...ignoring ...FAILED->BaselineOfWillowBootstrap'Errors in script loaded from /builds/macta/WillowPagerDuty/build/loadProject.st' Could not resolve: BaselineOfWillowBootstrap [BaselineOfWillowBootstrap] in /builds/macta/WillowPagerDuty/build/pharo-local/package-cache https://github.com/github/ba-st/Willow-Bootstrap:v8/source ERROR: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: ZnHttpUnsuccessful: 404 Not Found' MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: [ | references nearestReference cachedReference externalReference mcVersion loadedVersionInfos | cachedReference := nil. packageSpec searchCacheRepositoryForPackage: [ "check to see if mcz file is already in cacheRepository" cachedReference := self resolvePackageSpec: packageSpec cachedGofer: self loaderPolicy cacheGofer. (cachedReference ~~ nil and: [ packageSpec getFile ~~ nil ]) ifTrue: [ cachedReference name = packageSpec file ifTrue: [ "exact match between packageSpec file and cache" ^ self scheduleFetchFor: packageSpec cachedReference: cachedReference ] ] ]. references := self retryingResolvePackageSpecReferences: packageSpec gofer: gofer. "look up mcz file" nearestReference := references last asMetacelloCachingResolvedReference. (cachedReference ~~ nil and: [ cachedReference name = nearestReference name ]) ifTrue: [ "latest reference in repository matches cachedReference ... " ^ self Sent from my iPhone
On 15 May 2018, at 06:51, Guillermo Polito <guillermopolito@gmail.com> wrote:
Also, are you in Pharo6 or 7?
Hi Guillermo - so here are the actual log files and the .st Iâm running with build.sh (its a normal pharo command line execution). Its running on Ubuntu 17.10, with Pharo 6.1 64 bit. I got Pharo like this: VM_STRATEGY="vmI61"; curl http://get.pharo.org/64/$VM_STRATEGY | bash; curl get.pharo.org/64/61 | bash; The error at the top of the log is: LGit_GIT_ERROR: SSL error: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init 15 May 2018 3:01:38.976377 am And a few lines down you see it has translated the github:// url (in the baseline package) to https but then it seems to fail⦠although is that https translation correct? I have also tried specifying https repos in the baseline myself (but you canât easily control the baselines it in turn refers to) but that didnât work either. LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'https://github.com/ba-st/Willow-Bootstrap.git' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap isOpen: nil workingDirectory: nil I was successfully doing something like this months ago with PharoLambda - but I suspect if I rerun that pipeline it may also fail like this. Tim
On 15 May 2018, at 09:36, Tim Mackinnon <tim@testit.works> wrote:
Hi - Iâll extract the log files when Iâm at my desk I can possibly make the pipeline public so you can better see it - and itâs a relatively simple app so maybe it can shed some light (although Iâm still not ruling out my own stupidity yet).
Itâs a Pharo 6.1 64 bit image - download on build, applied to Ubuntu 17.10 (the same happens with 16.04).
Tim
The initial error is:
Starting Load Script...
Configure Load caches... Loading Projects...
Fetched -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src Loaded -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src --- tonel:///builds/macta/WillowPagerDuty/src Loading baseline of BaselineOfPagerDuty... ...RETRY->BaselineOfWillowBootstrap ...RETRY->BaselineOfWillowBootstrap gofer repository error: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: ZnHttpUnsuccessful: 404 Not Found'...ignoring ...FAILED->BaselineOfWillowBootstrap'Errors in script loaded from /builds/macta/WillowPagerDuty/build/loadProject.st' Could not resolve: BaselineOfWillowBootstrap [BaselineOfWillowBootstrap] in /builds/macta/WillowPagerDuty/build/pharo-local/package-cache https://github.com/github/ba-st/Willow-Bootstrap:v8/source ERROR: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: ZnHttpUnsuccessful: 404 Not Found' MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: [ | references nearestReference cachedReference externalReference mcVersion loadedVersionInfos | cachedReference := nil. packageSpec searchCacheRepositoryForPackage: [ "check to see if mcz file is already in cacheRepository" cachedReference := self resolvePackageSpec: packageSpec cachedGofer: self loaderPolicy cacheGofer. (cachedReference ~~ nil and: [ packageSpec getFile ~~ nil ]) ifTrue: [ cachedReference name = packageSpec file ifTrue: [ "exact match between packageSpec file and cache" ^ self scheduleFetchFor: packageSpec cachedReference: cachedReference ] ] ]. references := self retryingResolvePackageSpecReferences: packageSpec gofer: gofer. "look up mcz file" nearestReference := references last asMetacelloCachingResolvedReference. (cachedReference ~~ nil and: [ cachedReference name = nearestReference name ]) ifTrue: [ "latest reference in repository matches cachedReference ... " ^ self
Sent from my iPhone
On 15 May 2018, at 06:51, Guillermo Polito <guillermopolito@gmail.com> wrote:
Also, are you in Pharo6 or 7?
hi Tim, you cannot use vm âIâ (for Itimer) with iceberg. This timer will kill the SSH sockets. you need the âthreadedâ VM (which is the default, for obvious reasons :P). cheers, Esteban
On 15 May 2018, at 12:18, Tim Mackinnon <tim@testit.works> wrote:
Hi Guillermo - so here are the actual log files and the .st Iâm running with build.sh (its a normal pharo command line execution). Its running on Ubuntu 17.10, with Pharo 6.1 64 bit.
I got Pharo like this:
VM_STRATEGY="vmI61"; curl http://get.pharo.org/64/$VM_STRATEGY <http://get.pharo.org/64/$VM_STRATEGY> | bash; curl get.pharo.org/64/61 <http://get.pharo.org/64/61> | bash;
The error at the top of the log is: LGit_GIT_ERROR: SSL error: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init 15 May 2018 3:01:38.976377 am
And a few lines down you see it has translated the github:// url (in the baseline package) to https but then it seems to fail⦠although is that https translation correct? I have also tried specifying https repos in the baseline myself (but you canât easily control the baselines it in turn refers to) but that didnât work either.
LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'https://github.com/ba-st/Willow-Bootstrap.git <https://github.com/ba-st/Willow-Bootstrap.git>' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap isOpen: nil workingDirectory: nil
I was successfully doing something like this months ago with PharoLambda - but I suspect if I rerun that pipeline it may also fail like this.
Tim
<PharoDebug.log> <loadProject.st> <LoadProject.log> <build.sh> <BaselineOfPagerDuty.class.st>
On 15 May 2018, at 09:36, Tim Mackinnon <tim@testit.works <mailto:tim@testit.works>> wrote:
Hi - Iâll extract the log files when Iâm at my desk I can possibly make the pipeline public so you can better see it - and itâs a relatively simple app so maybe it can shed some light (although Iâm still not ruling out my own stupidity yet).
Itâs a Pharo 6.1 64 bit image - download on build, applied to Ubuntu 17.10 (the same happens with 16.04).
Tim
The initial error is:
Starting Load Script...
Configure Load caches... Loading Projects...
Fetched -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> Loaded -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> Loading baseline of BaselineOfPagerDuty... ...RETRY->BaselineOfWillowBootstrap ...RETRY->BaselineOfWillowBootstrap gofer repository error: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: <https://github.com/github/ba-st/Willow-Bootstrap:v8/source:> ZnHttpUnsuccessful: 404 Not Found'...ignoring ...FAILED->BaselineOfWillowBootstrap'Errors in script loaded from /builds/macta/WillowPagerDuty/build/loadProject.st <http://loadproject.st/>' Could not resolve: BaselineOfWillowBootstrap [BaselineOfWillowBootstrap] in /builds/macta/WillowPagerDuty/build/pharo-local/package-cache https://github.com/github/ba-st/Willow-Bootstrap:v8/source <https://github.com/github/ba-st/Willow-Bootstrap:v8/source> ERROR: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: <https://github.com/github/ba-st/Willow-Bootstrap:v8/source:> ZnHttpUnsuccessful: 404 Not Found' MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: [ | references nearestReference cachedReference externalReference mcVersion loadedVersionInfos | cachedReference := nil. packageSpec searchCacheRepositoryForPackage: [ "check to see if mcz file is already in cacheRepository" cachedReference := self resolvePackageSpec: packageSpec cachedGofer: self loaderPolicy cacheGofer. (cachedReference ~~ nil and: [ packageSpec getFile ~~ nil ]) ifTrue: [ cachedReference name = packageSpec file ifTrue: [ "exact match between packageSpec file and cache" ^ self scheduleFetchFor: packageSpec cachedReference: cachedReference ] ] ]. references := self retryingResolvePackageSpecReferences: packageSpec gofer: gofer. "look up mcz file" nearestReference := references last asMetacelloCachingResolvedReference. (cachedReference ~~ nil and: [ cachedReference name = nearestReference name ]) ifTrue: [ "latest reference in repository matches cachedReference ... " ^ self
Sent from my iPhone
On 15 May 2018, at 06:51, Guillermo Polito <guillermopolito@gmail.com <mailto:guillermopolito@gmail.com>> wrote:
Also, are you in Pharo6 or 7?
Ah - well that would be one problem then - I was using that to avoid that warning message you get as I didnât think I had privileges to do what it said - however it seems it would be better to have a proper docker container to run my CI builds in, and so I can probably solve it that way (the iTimer VM was something I picked up from PharoLambda - as you really canât control that environment at all - but it doesnât run Iceberg). Iâll make that correction and try again. Thanks, Tim
On 15 May 2018, at 12:28, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
hi Tim,
you cannot use vm âIâ (for Itimer) with iceberg. This timer will kill the SSH sockets. you need the âthreadedâ VM (which is the default, for obvious reasons :P).
cheers, Esteban
On 15 May 2018, at 12:18, Tim Mackinnon <tim@testit.works <mailto:tim@testit.works>> wrote:
Hi Guillermo - so here are the actual log files and the .st Iâm running with build.sh (its a normal pharo command line execution). Its running on Ubuntu 17.10, with Pharo 6.1 64 bit.
I got Pharo like this:
VM_STRATEGY="vmI61"; curl http://get.pharo.org/64/$VM_STRATEGY <http://get.pharo.org/64/$VM_STRATEGY> | bash; curl get.pharo.org/64/61 <http://get.pharo.org/64/61> | bash;
The error at the top of the log is: LGit_GIT_ERROR: SSL error: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init 15 May 2018 3:01:38.976377 am
And a few lines down you see it has translated the github:// url (in the baseline package) to https but then it seems to fail⦠although is that https translation correct? I have also tried specifying https repos in the baseline myself (but you canât easily control the baselines it in turn refers to) but that didnât work either.
LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'https://github.com/ba-st/Willow-Bootstrap.git <https://github.com/ba-st/Willow-Bootstrap.git>' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap isOpen: nil workingDirectory: nil
I was successfully doing something like this months ago with PharoLambda - but I suspect if I rerun that pipeline it may also fail like this.
Tim
<PharoDebug.log> <loadProject.st <http://loadproject.st/>> <LoadProject.log> <build.sh> <BaselineOfPagerDuty.class.st <http://baselineofpagerduty.class.st/>>
On 15 May 2018, at 09:36, Tim Mackinnon <tim@testit.works <mailto:tim@testit.works>> wrote:
Hi - Iâll extract the log files when Iâm at my desk I can possibly make the pipeline public so you can better see it - and itâs a relatively simple app so maybe it can shed some light (although Iâm still not ruling out my own stupidity yet).
Itâs a Pharo 6.1 64 bit image - download on build, applied to Ubuntu 17.10 (the same happens with 16.04).
Tim
The initial error is:
Starting Load Script...
Configure Load caches... Loading Projects...
Fetched -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> Loaded -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> Loading baseline of BaselineOfPagerDuty... ...RETRY->BaselineOfWillowBootstrap ...RETRY->BaselineOfWillowBootstrap gofer repository error: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: <https://github.com/github/ba-st/Willow-Bootstrap:v8/source:> ZnHttpUnsuccessful: 404 Not Found'...ignoring ...FAILED->BaselineOfWillowBootstrap'Errors in script loaded from /builds/macta/WillowPagerDuty/build/loadProject.st <http://loadproject.st/>' Could not resolve: BaselineOfWillowBootstrap [BaselineOfWillowBootstrap] in /builds/macta/WillowPagerDuty/build/pharo-local/package-cache https://github.com/github/ba-st/Willow-Bootstrap:v8/source <https://github.com/github/ba-st/Willow-Bootstrap:v8/source> ERROR: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: <https://github.com/github/ba-st/Willow-Bootstrap:v8/source:> ZnHttpUnsuccessful: 404 Not Found' MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: [ | references nearestReference cachedReference externalReference mcVersion loadedVersionInfos | cachedReference := nil. packageSpec searchCacheRepositoryForPackage: [ "check to see if mcz file is already in cacheRepository" cachedReference := self resolvePackageSpec: packageSpec cachedGofer: self loaderPolicy cacheGofer. (cachedReference ~~ nil and: [ packageSpec getFile ~~ nil ]) ifTrue: [ cachedReference name = packageSpec file ifTrue: [ "exact match between packageSpec file and cache" ^ self scheduleFetchFor: packageSpec cachedReference: cachedReference ] ] ]. references := self retryingResolvePackageSpecReferences: packageSpec gofer: gofer. "look up mcz file" nearestReference := references last asMetacelloCachingResolvedReference. (cachedReference ~~ nil and: [ cachedReference name = nearestReference name ]) ifTrue: [ "latest reference in repository matches cachedReference ... " ^ self
Sent from my iPhone
On 15 May 2018, at 06:51, Guillermo Polito <guillermopolito@gmail.com <mailto:guillermopolito@gmail.com>> wrote:
Also, are you in Pharo6 or 7?
you can safely ignore that warning in most cases (in fact, I was thinking on removing it and replace for a small log or even nothing). cheers, Esteban
On 15 May 2018, at 14:42, Tim Mackinnon <tim@testit.works> wrote:
Ah - well that would be one problem then - I was using that to avoid that warning message you get as I didnât think I had privileges to do what it said - however it seems it would be better to have a proper docker container to run my CI builds in, and so I can probably solve it that way (the iTimer VM was something I picked up from PharoLambda - as you really canât control that environment at all - but it doesnât run Iceberg).
Iâll make that correction and try again.
Thanks,
Tim
On 15 May 2018, at 12:28, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
hi Tim,
you cannot use vm âIâ (for Itimer) with iceberg. This timer will kill the SSH sockets. you need the âthreadedâ VM (which is the default, for obvious reasons :P).
cheers, Esteban
On 15 May 2018, at 12:18, Tim Mackinnon <tim@testit.works <mailto:tim@testit.works>> wrote:
Hi Guillermo - so here are the actual log files and the .st Iâm running with build.sh (its a normal pharo command line execution). Its running on Ubuntu 17.10, with Pharo 6.1 64 bit.
I got Pharo like this:
VM_STRATEGY="vmI61"; curl http://get.pharo.org/64/$VM_STRATEGY <http://get.pharo.org/64/$VM_STRATEGY> | bash; curl get.pharo.org/64/61 <http://get.pharo.org/64/61> | bash;
The error at the top of the log is: LGit_GIT_ERROR: SSL error: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init 15 May 2018 3:01:38.976377 am
And a few lines down you see it has translated the github:// url (in the baseline package) to https but then it seems to fail⦠although is that https translation correct? I have also tried specifying https repos in the baseline myself (but you canât easily control the baselines it in turn refers to) but that didnât work either.
LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'https://github.com/ba-st/Willow-Bootstrap.git <https://github.com/ba-st/Willow-Bootstrap.git>' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-local/iceberg/ba-st/Willow-Bootstrap isOpen: nil workingDirectory: nil
I was successfully doing something like this months ago with PharoLambda - but I suspect if I rerun that pipeline it may also fail like this.
Tim
<PharoDebug.log> <loadProject.st <http://loadproject.st/>> <LoadProject.log> <build.sh> <BaselineOfPagerDuty.class.st <http://baselineofpagerduty.class.st/>>
On 15 May 2018, at 09:36, Tim Mackinnon <tim@testit.works <mailto:tim@testit.works>> wrote:
Hi - Iâll extract the log files when Iâm at my desk I can possibly make the pipeline public so you can better see it - and itâs a relatively simple app so maybe it can shed some light (although Iâm still not ruling out my own stupidity yet).
Itâs a Pharo 6.1 64 bit image - download on build, applied to Ubuntu 17.10 (the same happens with 16.04).
Tim
The initial error is:
Starting Load Script...
Configure Load caches... Loading Projects...
Fetched -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> Loaded -> BaselineOfPagerDuty-tonel.1 --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> --- tonel:///builds/macta/WillowPagerDuty/src <tonel:///builds/macta/WillowPagerDuty/src> Loading baseline of BaselineOfPagerDuty... ...RETRY->BaselineOfWillowBootstrap ...RETRY->BaselineOfWillowBootstrap gofer repository error: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: <https://github.com/github/ba-st/Willow-Bootstrap:v8/source:> ZnHttpUnsuccessful: 404 Not Found'...ignoring ...FAILED->BaselineOfWillowBootstrap'Errors in script loaded from /builds/macta/WillowPagerDuty/build/loadProject.st <http://loadproject.st/>' Could not resolve: BaselineOfWillowBootstrap [BaselineOfWillowBootstrap] in /builds/macta/WillowPagerDuty/build/pharo-local/package-cache https://github.com/github/ba-st/Willow-Bootstrap:v8/source <https://github.com/github/ba-st/Willow-Bootstrap:v8/source> ERROR: 'GoferRepositoryError: Could not access https://github.com/github/ba-st/Willow-Bootstrap:v8/source: <https://github.com/github/ba-st/Willow-Bootstrap:v8/source:> ZnHttpUnsuccessful: 404 Not Found' MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: [ | references nearestReference cachedReference externalReference mcVersion loadedVersionInfos | cachedReference := nil. packageSpec searchCacheRepositoryForPackage: [ "check to see if mcz file is already in cacheRepository" cachedReference := self resolvePackageSpec: packageSpec cachedGofer: self loaderPolicy cacheGofer. (cachedReference ~~ nil and: [ packageSpec getFile ~~ nil ]) ifTrue: [ cachedReference name = packageSpec file ifTrue: [ "exact match between packageSpec file and cache" ^ self scheduleFetchFor: packageSpec cachedReference: cachedReference ] ] ]. references := self retryingResolvePackageSpecReferences: packageSpec gofer: gofer. "look up mcz file" nearestReference := references last asMetacelloCachingResolvedReference. (cachedReference ~~ nil and: [ cachedReference name = nearestReference name ]) ifTrue: [ "latest reference in repository matches cachedReference ... " ^ self
Sent from my iPhone
On 15 May 2018, at 06:51, Guillermo Polito <guillermopolito@gmail.com <mailto:guillermopolito@gmail.com>> wrote:
Also, are you in Pharo6 or 7?
Le 15/05/2018 à 14:45, Esteban Lorenzano a écrit :
you can safely ignore that warning in most cases (in fact, I was thinking on removing it and replace for a small log or even nothing).
It would be great! Most of the time it just makes noise in the CI logs :( There is a PR to remove this warning in the VM repo (https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/144) But there is no review. It dates from July 2017.
cheers, Esteban
-- Cyril Ferlicot https://ferlicot.fr
EstebanLM wrote
you cannot use vm âIâ (for Itimer) with iceberg.
I was guessing VM as well, or 64 bit, because those were the obvious differences between my setup and yours. The only part I found hard at all on Gitlab was loading other private projects from Gitlab, which require a bit of infrastructure with SSH keys and secret variables (let me know if you ever run into this!). ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
participants (7)
-
Cyril Ferlicot D. -
Esteban Lorenzano -
Fabio Niephaus -
Guillermo Polito -
Peter Uhnák -
Sean P. DeNigris -
Tim Mackinnon