[Pharo-users] Pharo + git workflow

Norbert Hartl norbert at hartl.name
Mon Jan 25 16:03:38 EST 2016


Hi Thierry,

> Am 25.01.2016 um 21:36 schrieb Thierry Goubier <thierry.goubier at gmail.com>:
> 
> Hi Norbert,
> 
> Le 25/01/2016 21:17, Norbert Hartl a écrit :
>> Hi Thierry,
>> 
>>> Am 25.01.2016 um 20:45 schrieb Thierry Goubier
>>> <thierry.goubier at gmail.com <mailto:thierry.goubier at gmail.com>>:
>>> 
>>> Hi Norbert,
>>> 
>>> Le 25/01/2016 20:01, Norbert Hartl a écrit :
>>>> 
>>>>> Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert at hartl.name
>>>>> <mailto:norbert at hartl.name>>:
>>>>> 
>>>>> I'm eager to try a new project with some git repositories. But to
>>>>> be honest I don't really get it. Searching the web there is lots to
>>>>> find but nothing actual.
>>>>> 
>>>>> I don't understand if it is ok to use a ConfigurationOf or if it
>>>>> only works with a BaselineOf. And how do you specify the repository
>>>>> in a ConfigurationOf in order to be able to work locally as well as
>>>>> having jenkins pull everything automatically? Same goes for
>>>>> dependent projects.
>>>>> 
>>>>> Are there any insights to this or pointers to an up-to-date
>>>>> documentation?
>>>>> 
>>>> My own insights so far when using git:
>>>> 
>>>> - I need to use BaselineOf instead of ConfigurationOf. Thus you
>>>> cannot use Versionner anymore
>>> 
>>> You can use ConfigurationOf. BaselineOf is only there to help.
>>> 
>> Ok, good to know.
>> 
>>>> - I need to load metacello-work from github in order to use
>>>> bitbucket:// repositories
>>> 
>>> This should be an issue for Pharo.
>>> 
>>>> - Metacello downloads a zip file from the repository to install code.
>>>> I have no glue how I can download things locally in order to work on
>>>> the code
>>> 
>>> Metacello github:// and bitbucket:// urls are only for read-only access
>>> to the packages (distribution).
>>> 
>>> Metacello install the contents of the zip into a path composed of
>>> github-cache (or bitbucket-cache I guess), the repository name, person
>>> name, commit id or version as a filetree repository. You can add that
>>> repository as a filetree repository inside Monticello if you want. But
>>> it is read-only.
>>> 
>> That is ok if you produce a deployment artefact, e.g. with jenkins. But
>> there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
>> 
>>> Download locally is done by either a git clone on the command line or by
>>> a GitFileTree remote repository addition.
>>> 
>>>> - Specifying a path to access a sub-directory of the repository seems
>>>> not to be possible
>>> 
>>> It is: url format is
>>> [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
>> 
>> It works without sub-directory. With it throws an error
>> 
>> 'Git error: Cloning into ''st''...
>> conq: invalid command syntax.
>> fatal: Could not read from remote repository.
>> 
>> Please make sure you have the correct access rights
>> and the repository exists.
> 
> Oh, I see. You're using the stable version of GitFileTree in Pharo4, isn't it?
> 
Yes.

> I haven't pushed the changes for the url syntax in that version. So the old syntax becomes:
> 
> gitfiletree://example.com/path/to/repo?dir=sub-directory&branch=commit
> 
Does not work for me. Same error.

> My problem is that the new url syntax is in the same package as the metadata-less mode of GitFileTree, and that mode supposes a fix to FileTree (a single method!). Maybe I'll switch the Pharo4 development version to not create metadata-less repositories.
> 
>>> It is also allways possible to reopen a filetree or a gitfiletree repo
>>> on a sub-directory of the main repository... this is how FileTree itself
>>> is tested for integration.
>>> 
>>>> - I don't know where to specify credentials because I have a private
>>>> repo on bitbucket
>>> 
>>> If you have a ssh key, then GitFileTree will pick it up for you.
>>> 
>> Yes, that is my preferred way, too.
> 
> Well, that one really had to work :)
> 
It is a good approach. I guess the pharo code uses the library and the library uses ssh. And ssh inquires ssh-agent. Exactly as it should IMHO.

>>>> My conclusion is that if you don't want to use versionner and you
>>>> have public projects on github using that stuff might seem feasible.
>>>> If any of those is different it won't work. Right?
>>> 
>>> No, it works and has been working for git access to private
>>> repositories, bitbucket included, for years... at least on Linux ;)
>>> 
>> Ok, thanks, if the sub-directory stuff would work it would be ok to jump
>> in. Maybe there is a way to tweak the url in the baseline. It would
>> remove the need to install gitfiletree in a deployment artefact. We'll see.
> 
> In a deployment artefact, then it becomes a bit different because your repo is then public.
> 
Why so? Because specifying the credentials is not possible?

> What I did for a Pharo4 deployment was to write a context dependent Makefile which uses filetree if I'm dealing with an archive of my artefact, and gitfiletree if it is build from a development repo.
> 
To me it boils down to what you can utilize in jenkins. 

>> Thanks again,
> 
> You're welcome. I'll update GitFileTree for Pharo4 soon and recommend that you use the development version.
> 
Good to hear. I'll test the development version then.

thanks,

Norbert





More information about the Pharo-users mailing list