Le 25/01/2016 22:03, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 21:36 schrieb Thierry Goubier
<thierry.goub...@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.goub...@gmail.com
<mailto:thierry.goub...@gmail.com>>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl
<norb...@hartl.name <mailto:norb...@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.
I tried in Pharo3 and that works. Strange. Can you see what is missing
from the git clone command when the error is raised? You should see a
string or an array with the command almost complete.
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.
Agreed.
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?
Hum, because I don't really know to pass credentials unless by
registering an ssh key.
Mind you, I didn't really look into that :(
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.
Just say how you would do that with something else and a git repository,
and I think that can be reproduced or added.
Thierry
