Hello, Using github://<github_path>/<srcpath> metacello works fine, but is there another more general way of refering to a remote git repo? From BitBucket or Gitlab for example. Regards, Vitor
Le 19/12/2017 à 19:25, Vitor Medina Cruz a écrit :
Hello,
Using github://<github_path>/<srcpath> metacello works fine, but is there another more general way of refering to a remote git repo? From BitBucket or Gitlab for example.
Hi, For bitbucket you can use bitbucket://. I don't know for gitlab. Anyway, we are talking about the possibility to use custom URLs that would also allow to depend on a git repository from a private server. See discussion at: https://github.com/Metacello/metacello/issues/474
Regards, Vitor
-- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Thanks. On Tue, Dec 19, 2017 at 4:40 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com
wrote:
Le 19/12/2017 à 19:25, Vitor Medina Cruz a écrit :
Hello,
Using github://<github_path>/<srcpath> metacello works fine, but is there another more general way of refering to a remote git repo? From BitBucket or Gitlab for example.
Hi,
For bitbucket you can use bitbucket://. I don't know for gitlab.
Anyway, we are talking about the possibility to use custom URLs that would also allow to depend on a git repository from a private server.
See discussion at: https://github.com/Metacello/metacello/issues/474
Regards, Vitor
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Vitor Medina Cruz wrote
I don't know for gitlab.
It doesn't seem to work (in Pharo 6.1). `LGit_GIT_EEOF`. I see there is MCBitbucketRepository but no MCGitlabRepository. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On 2 Jan 2018, at 16:43, Sean P. DeNigris <sean@clipperadams.com> wrote:
Vitor Medina Cruz wrote
I don't know for gitlab.
It doesn't seem to work (in Pharo 6.1). `LGit_GIT_EEOF`. I see there is MCBitbucketRepository but no MCGitlabRepository.
MC*Repository is not iceberg but monticello api. Iceberg supports gitlab projects (both public and private servers) and I know there is people using them. If you are getting LGit_GIT_EEOF is likely a bug or a problem when declaring repo⦠but the information you are giving is not enough to know :) Esteban
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
EstebanLM wrote
MC*Repository is not iceberg but monticello api.
Except it is extended by Iceberg-Adapters for #httpsUrl and #scpUrl! Also, MCBitbucketRepository is hardcoded in IceProviderRepositoryType>>#mcRepository, which was mangling the URL (off the top of my head I assume because 'bitbucket' is longer than 'gitlab'). This is all in #60528. I don't see how people could be using this unless it's fixed in 7.0 (which it doesn't appear to be because there still seems not to be an MCGitlabRepository) or they are using filetree:// or similar URLs in their baselines. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
if you have iceberg metacello integration enabled (default in 7.0), the repository is resolved as part of iceberg and then it does not instances a MC*Repository but an IceMetacelloRepositoryAdaptor. Then it works on baselines, etc. Esteban
On 2 Jan 2018, at 17:18, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
MC*Repository is not iceberg but monticello api.
Except it is extended by Iceberg-Adapters for #httpsUrl and #scpUrl! Also, MCBitbucketRepository is hardcoded in IceProviderRepositoryType>>#mcRepository, which was mangling the URL (off the top of my head I assume because 'bitbucket' is longer than 'gitlab'). This is all in #60528. I don't see how people could be using this unless it's fixed in 7.0 (which it doesn't appear to be because there still seems not to be an MCGitlabRepository) or they are using filetree:// or similar URLs in their baselines.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
EstebanLM wrote
if you have iceberg metacello integration enabled⦠Then it works on baselines, etc.
Strange. I did `Iceberg enableMetacelloIntegration: true.` first and still got the error. I can't easily test in 7 because it depends on Magritte which depends on Grease which doesn't seem to load yet. Maybe I can cobble together a simpler test case. The Git error I mentioned in my OP was caused because `LGitRepository >> clone:options:to:` is trying to clone 'git@bitbucket.org:nDeNigris/Quote-Me.git' based on `gitlab://SeanDeNigris/Quote-Me:master/repository` from the baseline spec. Earlier in the stack, `IceProviderRepositoryType >> mcRepository` is using `MCBitbucketRepository` which is hardcoded. All of the above is with iceberg metacello integration enabled. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Sean, On 2 January 2018 at 18:00, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
if you have iceberg metacello integration enabled⦠Then it works on baselines, etc.
Strange. I did `Iceberg enableMetacelloIntegration: true.` first and still got the error. I can't easily test in 7 because it depends on Magritte which depends on Grease which doesn't seem to load yet. Maybe I can cobble together a simpler test case.
This may not help, but... Pharo 7.0 Build information: Pharo-7.0+alpha.build.398.sha.52a28a857deec25612d302aba8ab09bdd6212b31 (32 Bit) I have Pillar loaded, which in turn loads: ConfigurationOfMagritte3-topa.126 Magritte-Model-SeanDeNigris.465 Magritte-Morph-SeanDeNigris.95 Magritte-Pharo3-Model-JohnCBorden.4 ConfigurationOfGrease-StephanEggermont.348 Grease-Core-JohanBrichau.97 Grease-Pharo30-Core-PavelKrivanek.22 The image was built about 4 days ago. HTH, Alistair
The Git error I mentioned in my OP was caused because `LGitRepository >> clone:options:to:` is trying to clone 'git@bitbucket.org:nDeNigris/Quote-Me.git' based on `gitlab://SeanDeNigris/Quote-Me:master/repository` from the baseline spec. Earlier in the stack, `IceProviderRepositoryType >> mcRepository` is using `MCBitbucketRepository` which is hardcoded.
All of the above is with iceberg metacello integration enabled.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Alistair About pillar, we are working on a new pipeline and lot of cleaning compared to the version available on smalltalkhub. The new version Branch new pipeline seems broken (I will check it tomorrow it cannot handle internal references). I want to be able to build the old books with the new version. Now it is not working. Stef On Tue, Jan 2, 2018 at 6:08 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Sean,
On 2 January 2018 at 18:00, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
if you have iceberg metacello integration enabled⦠Then it works on baselines, etc.
Strange. I did `Iceberg enableMetacelloIntegration: true.` first and still got the error. I can't easily test in 7 because it depends on Magritte which depends on Grease which doesn't seem to load yet. Maybe I can cobble together a simpler test case.
This may not help, but...
Pharo 7.0 Build information: Pharo-7.0+alpha.build.398.sha.52a28a857deec25612d302aba8ab09bdd6212b31 (32 Bit)
I have Pillar loaded, which in turn loads:
ConfigurationOfMagritte3-topa.126 Magritte-Model-SeanDeNigris.465 Magritte-Morph-SeanDeNigris.95 Magritte-Pharo3-Model-JohnCBorden.4 ConfigurationOfGrease-StephanEggermont.348 Grease-Core-JohanBrichau.97 Grease-Pharo30-Core-PavelKrivanek.22
The image was built about 4 days ago.
HTH, Alistair
The Git error I mentioned in my OP was caused because `LGitRepository >> clone:options:to:` is trying to clone 'git@bitbucket.org:nDeNigris/Quote-Me.git' based on `gitlab://SeanDeNigris/Quote-Me:master/repository` from the baseline spec. Earlier in the stack, `IceProviderRepositoryType >> mcRepository` is using `MCBitbucketRepository` which is hardcoded.
All of the above is with iceberg metacello integration enabled.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Stef, On 2 January 2018 at 20:11, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Alistair
About pillar, we are working on a new pipeline and lot of cleaning compared to the version available on smalltalkhub. The new version Branch new pipeline seems broken (I will check it tomorrow it cannot handle internal references). I want to be able to build the old books with the new version. Now it is not working.
Stef
Yep, I remember you also mentioning that you're planning to decouple the core Pillar from Magritte and Grease. All of this will make our lives easier. Thanks, Alistair
On Tue, Jan 2, 2018 at 6:08 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Sean,
On 2 January 2018 at 18:00, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
if you have iceberg metacello integration enabled⦠Then it works on baselines, etc.
Strange. I did `Iceberg enableMetacelloIntegration: true.` first and still got the error. I can't easily test in 7 because it depends on Magritte which depends on Grease which doesn't seem to load yet. Maybe I can cobble together a simpler test case.
This may not help, but...
Pharo 7.0 Build information: Pharo-7.0+alpha.build.398.sha.52a28a857deec25612d302aba8ab09bdd6212b31 (32 Bit)
I have Pillar loaded, which in turn loads:
ConfigurationOfMagritte3-topa.126 Magritte-Model-SeanDeNigris.465 Magritte-Morph-SeanDeNigris.95 Magritte-Pharo3-Model-JohnCBorden.4 ConfigurationOfGrease-StephanEggermont.348 Grease-Core-JohanBrichau.97 Grease-Pharo30-Core-PavelKrivanek.22
The image was built about 4 days ago.
HTH, Alistair
The Git error I mentioned in my OP was caused because `LGitRepository >> clone:options:to:` is trying to clone 'git@bitbucket.org:nDeNigris/Quote-Me.git' based on `gitlab://SeanDeNigris/Quote-Me:master/repository` from the baseline spec. Earlier in the stack, `IceProviderRepositoryType >> mcRepository` is using `MCBitbucketRepository` which is hardcoded.
All of the above is with iceberg metacello integration enabled.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
About pillar, we are working on a new pipeline and lot of cleaning compared to the version available on smalltalkhub. The new version Branch new pipeline seems broken (I will check it tomorrow it cannot handle internal references). I want to be able to build the old books with the new version. Now it is not working.
Stef
Yep, I remember you also mentioning that you're planning to decouple the core Pillar from Magritte and Grease. All of this will make our lives easier.
There were some real glitches in the newpipeline and now I'm ready to produce a booklet. Now I will check and fix some more... And yes I want to remove the dependencies to Magritte and Grease and get a modular core. But first I want to arrive to a stable point and migrate all the books and booklets to Pillar 70. Then I will work on a new version of Cocoon and integrate it to pillar and remove magritte. Some I imagine that it may take me 6 months (because I'm doing far too many things). Stef
On 2 Jan 2018, at 18:00, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
if you have iceberg metacello integration enabled⦠Then it works on baselines, etc.
Strange. I did `Iceberg enableMetacelloIntegration: true.` first and still got the error. I can't easily test in 7 because it depends on Magritte which depends on Grease which doesn't seem to load yet. Maybe I can cobble together a simpler test case.
The Git error I mentioned in my OP was caused because `LGitRepository >> clone:options:to:` is trying to clone 'git@bitbucket.org:nDeNigris/Quote-Me.git' based on `gitlab://SeanDeNigris/Quote-Me:master/repository` from the baseline spec. Earlier in the stack, `IceProviderRepositoryType >> mcRepository` is using `MCBitbucketRepository` which is hardcoded.
All of the above is with iceberg metacello integration enabled.
yep. that seems to be a bug. Esteban
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
EstebanLM wrote
yep. that seems to be a bug.
Okay, I hacked a solution. Before I submit the fix I want to verify: no one has been successfully using gitlab:// URLs in a MetaC baseline spec for a private dependent project (accessed via SSH keys), right? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Am 03.01.2018 um 00:26 schrieb Sean P. DeNigris <sean@clipperadams.com>:
EstebanLM wrote
yep. that seems to be a bug.
Okay, I hacked a solution. Before I submit the fix I want to verify: no one has been successfully using gitlab:// URLs in a MetaC baseline spec for a private dependent project (accessed via SSH keys), right?
There were no classes to support it. Only github and bitbucket. So, yes!! Norbert
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
EstebanLM wrote
yep. that seems to be a bug.
20953: Gitlab Private Project Support (via Iceberg) https://pharo.fogbugz.com/f/cases/20953/ PRs issued - https://github.com/pharo-project/pharo/pull/667 - https://github.com/pharo-vcs/iceberg/pull/559 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Sean P. DeNigris wrote
20953: Gitlab Private Project Support (via Iceberg) https://pharo.fogbugz.com/f/cases/20953/
PRs issued - https://github.com/pharo-project/pharo/pull/667 - https://github.com/pharo-vcs/iceberg/pull/559
These both have been integrated. Will someone confirm they are able to load a private Gitlab project via Iceberg and SSH key authentication? You'll probably have to update Iceberg, which I'm not sure how to do. Esteban? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Sean P. DeNigris wrote
These both have been integrated.
Hmm, I'm confused. PR #667, which seems definitely to include MCGitlabRepository, has been merged into the dev branch [1], but MCGitlabRepository is not present in a fresh Pharo 7 image with "Build information: Pharo-7.0+alpha.build.438.sha.b28d466f661cbf73f9b63f91174032bcee843d26 (32 Bit)". Is this because the build aborted? I logged into Jenkins [2], but didn't see an option to restart the build⦠1. https://github.com/pharo-project/pharo/commit/b28d466f661cbf73f9b63f91174032... 2. https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20... ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
An image with build 454 seems still not to have MCGitlabRepository present. What am I missing? Same for build 462 with sha 3641442f3ba0613cd9a6428181487ea29e62418c, which has the package in its source: https://github.com/pharo-project/pharo/tree/3641442f3ba0613cd9a6428181487ea2... Ditto for build 487.sha.58ee23aadcd15e0a969ed675e8141c0cfd95594a ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
I've seen that the other day. The package is in the repository but is not loaded in the image. Probably somebody committed it but not added it into any baseline. On Fri, Feb 2, 2018 at 4:35 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
An image with build 454 seems still not to have MCGitlabRepository present. What am I missing? Same for build 462 with sha 3641442f3ba0613cd9a6428181487ea29e62418c, which has the package in its source: https://github.com/pharo-project/pharo/tree/3641442f3ba0613cd9a6428181487e a29e62418c/src/Metacello-Gitlab
Ditto for build 487.sha.58ee23aadcd15e0a969ed675e8141c0cfd95594a
----- 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
yes, I asked Pavel to look at it⦠Esteban
On 2 Feb 2018, at 09:38, Guillermo Polito <guillermopolito@gmail.com> wrote:
I've seen that the other day. The package is in the repository but is not loaded in the image. Probably somebody committed it but not added it into any baseline.
On Fri, Feb 2, 2018 at 4:35 AM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote: An image with build 454 seems still not to have MCGitlabRepository present. What am I missing? Same for build 462 with sha 3641442f3ba0613cd9a6428181487ea29e62418c, which has the package in its source: https://github.com/pharo-project/pharo/tree/3641442f3ba0613cd9a6428181487ea2... <https://github.com/pharo-project/pharo/tree/3641442f3ba0613cd9a6428181487ea2...>
Ditto for build 487.sha.58ee23aadcd15e0a969ed675e8141c0cfd95594a
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <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
the pull request was against the issue branch, not the development one, so the merging of it had no real effect. I created a new one ( https://github.com/pharo-project/pharo/pull/790) -- Pavel 2018-02-02 9:47 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
yes, I asked Pavel to look at itâ¦
Esteban
On 2 Feb 2018, at 09:38, Guillermo Polito <guillermopolito@gmail.com> wrote:
I've seen that the other day. The package is in the repository but is not loaded in the image. Probably somebody committed it but not added it into any baseline.
On Fri, Feb 2, 2018 at 4:35 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
An image with build 454 seems still not to have MCGitlabRepository present. What am I missing? Same for build 462 with sha 3641442f3ba0613cd9a6428181487ea29e62418c, which has the package in its source: https://github.com/pharo-project/pharo/tree/3641442f3ba0613c d9a6428181487ea29e62418c/src/Metacello-Gitlab
Ditto for build 487.sha.58ee23aadcd15e0a969ed675e8141c0cfd95594a
----- 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 <+33%206%2052%2070%2066%2013>
thanks!
On 2 Feb 2018, at 10:12, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
the pull request was against the issue branch, not the development one, so the merging of it had no real effect. I created a new one (https://github.com/pharo-project/pharo/pull/790 <https://github.com/pharo-project/pharo/pull/790>)
-- Pavel
2018-02-02 9:47 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: yes, I asked Pavel to look at itâ¦
Esteban
On 2 Feb 2018, at 09:38, Guillermo Polito <guillermopolito@gmail.com <mailto:guillermopolito@gmail.com>> wrote:
I've seen that the other day. The package is in the repository but is not loaded in the image. Probably somebody committed it but not added it into any baseline.
On Fri, Feb 2, 2018 at 4:35 AM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote: An image with build 454 seems still not to have MCGitlabRepository present. What am I missing? Same for build 462 with sha 3641442f3ba0613cd9a6428181487ea29e62418c, which has the package in its source: https://github.com/pharo-project/pharo/tree/3641442f3ba0613cd9a6428181487ea2... <https://github.com/pharo-project/pharo/tree/3641442f3ba0613cd9a6428181487ea2...>
Ditto for build 487.sha.58ee23aadcd15e0a969ed675e8141c0cfd95594a
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <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 <tel:+33%206%2052%2070%2066%2013>
Pavel Krivanek-3 wrote
the pull request was against the issue branch, not the development one, so the merging of it had no real effect
Oops, he he thanks. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
CyrilFerlicot wrote
For bitbucket you can use bitbucket://. I don't know for gitlab.
Unless something has changed, the cool git URLs only work for public projects. In any case, it was not possible to authenticate with SSH keys last time I checked (so I could not use them)⦠----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Sean, I am under the impression that iceberg is able to authenticate with SSH keys .... I am not a pharo/iceberg user myself, but it seems that iceberg should be able to fill that gap. Dale On 12/19/17 7:02 PM, Sean P. DeNigris wrote:
CyrilFerlicot wrote
For bitbucket you can use bitbucket://. I don't know for gitlab. Unless something has changed, the cool git URLs only work for public projects. In any case, it was not possible to authenticate with SSH keys last time I checked (so I could not use them)â¦
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Tue, Dec 19, 2017 at 07:07:16PM -0800, Dale Henrichs wrote:
I am under the impression that iceberg is able to authenticate with SSH keys .... I am not a pharo/iceberg user myself, but it seems that iceberg should be able to fill that gap.
Iceberg does, with RSA keys. Iceberg didn't work for me with ED25519 keys. Pierce
Hi Pierce, Le 20/12/2017 à 17:17, Pierce Ng a écrit :
On Tue, Dec 19, 2017 at 07:07:16PM -0800, Dale Henrichs wrote:
I am under the impression that iceberg is able to authenticate with SSH keys .... I am not a pharo/iceberg user myself, but it seems that iceberg should be able to fill that gap.
Iceberg does, with RSA keys. Iceberg didn't work for me with ED25519 keys.
does command line git work with those ED25519 keys? Regards, Thierry
Pierce
On Wed, Dec 20, 2017 at 06:08:16PM +0100, Thierry Goubier wrote:
Iceberg does, with RSA keys. Iceberg didn't work for me with ED25519 keys. does command line git work with those ED25519 keys?
Yes. I have been using GH with ED25519 keys. I added RSA keys to my GH setup specifically for Iceberg. I looked and found out that libssh2 or libgit2 (forgot which) used by Iceberg does not support ED25519 keys. Pierce
Am 20.12.2017 um 04:02 schrieb Sean P. DeNigris <sean@clipperadams.com>:
CyrilFerlicot wrote
For bitbucket you can use bitbucket://. I don't know for gitlab.
Unless something has changed, the cool git URLs only work for public projects. In any case, it was not possible to authenticate with SSH keys last time I checked (so I could not use them)â¦
Au contraire! It works really good with SSH keys. I work all day with it. I added support for bitbucket to iceberg because Iâm using bitbucket private repos in my company. Norbert
Hi, We also use private GitHub projects with Iceberg and it works fine. Cheers, Doru
On Dec 20, 2017, at 10:50 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 20.12.2017 um 04:02 schrieb Sean P. DeNigris <sean@clipperadams.com>:
CyrilFerlicot wrote
For bitbucket you can use bitbucket://. I don't know for gitlab.
Unless something has changed, the cool git URLs only work for public projects. In any case, it was not possible to authenticate with SSH keys last time I checked (so I could not use them)â¦
Au contraire! It works really good with SSH keys. I work all day with it. I added support for bitbucket to iceberg because Iâm using bitbucket private repos in my company.
Norbert
-- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."
Tudor Girba-2 wrote
We also use private GitHub projects with Iceberg and it works fine.
Au contraire! It works really good with SSH keys. I work all day with it. I added support for bitbucket to iceberg because Iâm using bitbucket private repos in my company.
This is very intriguing. So you're saying one can now use GH and BB URLs to access private repos in baselines for dependent projects and they will be loaded via SSH keys? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Am 21.12.2017 um 03:27 schrieb Sean P. DeNigris <sean@clipperadams.com>:
Tudor Girba-2 wrote
We also use private GitHub projects with Iceberg and it works fine.
Au contraire! It works really good with SSH keys. I work all day with it. I added support for bitbucket to iceberg because Iâm using bitbucket private repos in my company.
This is very intriguing. So you're saying one can now use GH and BB URLs to access private repos in baselines for dependent projects and they will be loaded via SSH keys?
Yes, I have projects that are loaded from bitbucket private repos and that have dependencies to public github and private bitbucket repos all at once. Not a problem on my dev machine. On jenkins it is more of a problem. There the ssh keys are provided by the jenkins server but if a dependent project is also private there needs to be ssh keys in the environment. Second thing is that the linux 64bit vm is pretty unstable. This could be avoided using filetree and zip downloads from git but there is no way providing credentials to the https download. Either way not good. I even made one project public in order to load it Norbert
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
NorbertHartl wrote
I have projects that are loaded from bitbucket private repos and that have dependencies to⦠private bitbucket repos all at once.
Is `Iceberg enableMetacelloIntegration: true` what gets around the tarball / SSH-support issue? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Am 21.12.2017 um 15:54 schrieb Sean P. DeNigris <sean@clipperadams.com>:
NorbertHartl wrote
I have projects that are loaded from bitbucket private repos and that have dependencies to⦠private bitbucket repos all at once.
Is `Iceberg enableMetacelloIntegration: true` what gets around the tarball / SSH-support issue?
Yes, metacello git integration will not download tarballs but checkout the git repo and therefor ssh can be used. Norbert
BitBucket is supported with like Github with: butbucket://<butbucket_path>/<srcpath>. With regards to GitLab, their download zip format is/was different enough from BitBucket/Github to make it difficult to provide the same level of support. See the series of comments here[1]. When the github:// was first introduced it was done in such a way that users of projects on GitHub did not have to have git installed on their local computers ... it was a way to make it possible for folks to begin using git without requiring everyone to install git ... These days, we are getting to the point where I am beginning to flip the question on it's head and begin thinking that it should be possible for a developer to choose to have have the github:// url interpreted as "create a local clone of the remote repository" instead of "download a tarball of the remote repository" . With this approach it should be possible to include gitlab url support as well since the gitlab issue is related to the specific handling of repository tarballs... ... there are current discussions in this area on these two issues [2] and [3]. Dale [1] https://github.com/Metacello/metacello/issues/287#issuecomment-59815235 [2] https://github.com/Metacello/metacello/issues/474 [3] https://github.com/Metacello/metacello/issues/475 On 12/19/17 10:25 AM, Vitor Medina Cruz wrote:
Hello,
Using github://<github_path>/<srcpath> metacello works fine, but is there another more general way of refering to a remote git repo? From BitBucket or Gitlab for example.
Regards, Vitor
These days, we are getting to the point where I am beginning to flip the question on it's head and begin thinking that it should be possible for a developer to choose to have have the github:// url interpreted as "create a local clone of the remote repository" instead of "download a tarball of the remote repository" . With this approach it should be possible to include gitlab url support as well since the gitlab issue is related to the specific handling of repository tarballs..
Using 'git clone --depth=1' don't do the trick and leave the process both efficient and general accross all git repos? On Tue, Dec 19, 2017 at 4:49 PM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
BitBucket is supported with like Github with: butbucket://<butbucket_path>/<srcpath>.
With regards to GitLab, their download zip format is/was different enough from BitBucket/Github to make it difficult to provide the same level of support. See the series of comments here[1].
When the github:// was first introduced it was done in such a way that users of projects on GitHub did not have to have git installed on their local computers ... it was a way to make it possible for folks to begin using git without requiring everyone to install git ...
These days, we are getting to the point where I am beginning to flip the question on it's head and begin thinking that it should be possible for a developer to choose to have have the github:// url interpreted as "create a local clone of the remote repository" instead of "download a tarball of the remote repository" . With this approach it should be possible to include gitlab url support as well since the gitlab issue is related to the specific handling of repository tarballs...
... there are current discussions in this area on these two issues [2] and [3].
Dale
[1] https://github.com/Metacello/metacello/issues/287#issuecomme nt-59815235
[2] https://github.com/Metacello/metacello/issues/474
[3] https://github.com/Metacello/metacello/issues/475
On 12/19/17 10:25 AM, Vitor Medina Cruz wrote:
Hello,
Using github://<github_path>/<srcpath> metacello works fine, but is there another more general way of refering to a remote git repo? From BitBucket or Gitlab for example.
Regards, Vitor
On 12/20/17 2:53 AM, Vitor Medina Cruz wrote:
These days, we are getting to the point where I am beginning to flip the question on it's head and begin thinking that it should be possible for a developer to choose to have have the github:// url interpreted as "create a local clone of the remote repository" instead of "download a tarball of the remote repository" . With this approach it should be possible to include gitlab url support as well since the gitlab issue is related to the specific handling of repository tarballs..
Using 'git clone --depth=1' don't do the trick and leave the process both efficient and general accross all git repos?
At the time that github:// was added (5 years ago now?) git could not be counted upon to be installed by the folks who may be interested in depending upon a project hosted on github, so the tarball approach was used so that those brave souls interested in using git and github could do so without forcing everyone else to start using git ... nowadays with git becoming part of the mainstream dev env for Smalltalk, git (or libgit2 in the case of pharo) can be counted on to be available ...
On Tue, Dec 19, 2017 at 4:49 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
BitBucket is supported with like Github with: butbucket://<butbucket_path>/<srcpath>.
With regards to GitLab, their download zip format is/was different enough from BitBucket/Github to make it difficult to provide the same level of support. See the series of comments here[1].
When the github:// was first introduced it was done in such a way that users of projects on GitHub did not have to have git installed on their local computers ... it was a way to make it possible for folks to begin using git without requiring everyone to install git ...
These days, we are getting to the point where I am beginning to flip the question on it's head and begin thinking that it should be possible for a developer to choose to have have the github:// url interpreted as "create a local clone of the remote repository" instead of "download a tarball of the remote repository" . With this approach it should be possible to include gitlab url support as well since the gitlab issue is related to the specific handling of repository tarballs...
... there are current discussions in this area on these two issues [2] and [3].
Dale
[1] https://github.com/Metacello/metacello/issues/287#issuecomment-59815235 <https://github.com/Metacello/metacello/issues/287#issuecomment-59815235>
[2] https://github.com/Metacello/metacello/issues/474 <https://github.com/Metacello/metacello/issues/474>
[3] https://github.com/Metacello/metacello/issues/475 <https://github.com/Metacello/metacello/issues/475>
On 12/19/17 10:25 AM, Vitor Medina Cruz wrote:
Hello,
Using github://<github_path>/<srcpath> metacello works fine, but is there another more general way of refering to a remote git repo? From BitBucket or Gitlab for example.
Regards, Vitor
participants (13)
-
Alistair Grant -
Cyril Ferlicot D. -
Dale Henrichs -
Esteban Lorenzano -
Guillermo Polito -
Norbert Hartl -
Pavel Krivanek -
Pierce Ng -
Sean P. DeNigris -
Stephane Ducasse -
Thierry Goubier -
Tudor Girba -
Vitor Medina Cruz