I made a PR to allow ���generic��� git repositories to be referenced:
But��� problem is more complicated than you may think: Metacello ���vanilla��� relies on download a zip file with the sources, it cannot have a ���generic��� way to act.
This means the PR will work just if you use iceberg. And maybe you do not want to declare your baselines relying on iceberg.
In that case, you have just one workaround possible:
1) clone locally the remove private sources outside the image.
2) load them using plain metacello and filetree://.
3) ���lock��� those repositories.
Then you can run your installation.
Esteban
Am 01.11.2019 um 17:44 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 31 Oct 2019, at 12:18, Norbert Hartl <norbert@hartl.name> wrote:
Am 31.10.2019 um 12:12 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 25 Oct 2019, at 14:49, Sven Van Caekenberghe <sven@stfx.eu> wrote:
How do you build/deploy non-public production code using the command line ?
I just learned about the following technique:
Using SSH agent forwarding
https://developer.github.com/v3/guides/using-ssh-agent-forwarding/
This certainly makes using certificates on production servers much easier since you do no longer have to manage or install special ones on the deployment servers, you can just use your standard developer certificates.
That is quite late :P I always use this as it also chains through all the machins you log in. We use jenkins for building our software there it does not work. We just have a deployment key for that. That is a key pair without passphrase that is registered in the git repository and installed on the jenkins server.
Norbert
Indeed, the SSH forwarding cannot be used for independent CI builds.
I am curious though: how do you do the initial checkout (clone) from your private repository ? Using regular git command line tools or using Iceberg/Metacello ?
If the latter, how do you specify your URL, exactly ?
The first case works for me too, using a gitlocal:// URL, but that is cheating a bit, I feel like we should be able to do this directly in Pharo.
If checking out from private repo your problem is as deep as you reference private repos. My project (1) is in a private repository, it contains a baseline that references a project in a private repository (2) and this references a project in a private repo (3).* Project (1) is checked out by jenkins. I have a deployment key pair without passphrase where the public key is registered in the bitbucket project and the private key is deployed on jenkins. * I try to avoid iceberg as much as possible for deployment builds because later I want to have an image without iceberg. And it is not reliable to use iceberg because metacello won't update git repos automatically and the odds are high that you load old content. So I load the project with the eval commandline handler with Metacello new repository: 'filetree://source'; baseline ��� ���* In order to load the private projects in the the baseline of the main project I run a script before build that hacks the image in a way thatMCBitbucketRepository compile: 'httpsUrl ^ ''https://USER:PASS@bitbucket.org/'', projectPath, ''.git'''.MCBitbucketRepository compile: 'projectZipUrlFor: projectPath versionString: versionString ^ ''https://USER:PASS@bitbucket.org/'' , projectPath , ''/get/'' , versionString , ''.zip'''.MCBitbucketRepository class compile: 'projectZipUrlFor: projectPath versionString: versionString ^ ''https://USER:PASS@bitbucket.org/'' , projectPath , ''/get/'' , versionString , ''.zip'''.This works only because all private projects are on bitbucket and no public one.* Project (3) I made public because I did not see how to make that workHope this helps. I feel this to be far too complicated. Together with the confusion between pharo5/pharo6/pharo7 with iceberg, tonel and iceberg and/or tonel support killed two weeks of my time at least. So I would welcome if there would be a better way to manage credentialsNorbert