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