[Gambas-user] Switching to GitLab

Adrien Prokopowicz adrien.prokopowicz at ...626...
Fri Aug 18 15:31:50 CEST 2017


Le Wed, 16 Aug 2017 23:14:54 +0200, Benoît Minisini  
<gambas at ...1...> a écrit:

> Le 16/08/2017 à 21:30, Adrien Prokopowicz a écrit :
>> Le Wed, 16 Aug 2017 18:30:03 +0200, Benoît Minisini via Gambas-user  
>> <gambas-user at lists.sourceforge.net> a écrit:
>>>
>>> It's because the download tool of GitLab downloads everything  
>>> (especially the 'MakeWebSite' project that has a lot big files in it),  
>>> whereas the "make dist-bzip2" command only package what is relevant to  
>>> compile and install Gambas.
>>>
>>> If no 'git' solution exist, maybe I will have to make these source  
>>> packages manually again, and store them on Sourceforge as usual...
>>>
>>  While there are no "git" solutions for this, maybe we should put the  
>> website in
>> its own repository, apart from the rest of the source tree ?
>> Same goes for the wiki, the bugtracker, etc.
>>
>
> Maybe. But the MakeWebSite project is not the only tool located in the  
> source tree. Or it may not be. It's just the one that takes a lot of  
> place. I will think about that.

Making separate repositories for each project is not a problem : we can  
have as
many repositories as we want in the Gambas group. :-)

Also, if the website is in its own repository, it can be hosted with the
GitLab Pages service (which I've never tried, but it seems similar to the  
hosting
provided by SourceForge).

>> (I can move it into a new repository without losing the history, if you  
>> want)
>>  As a side-note, we can also use GitLab's Pipelines feature to run the  
>> make
>> dist-bzip2 command and store the results every time we tag a new release
>> (we can also use it to distribute compiled binaries if we want).
>>
>
> Ha! This is more interesting. But "make dist-bzip2" is not enough. You  
> must run it after a full configuration of the source, so it must be run  
> on a clean system, and it needs to be hacked so that it can handle  
> symbolic links.
>

(I'm not sure what you mean by "it needs to be hacked so that it can handle
symbolic links". Doesn't every system handle symbolic links out-of-the-box  
?)

I forked the repository to make tests on my account, and I configured a
small pipeline thats configures the sources and then generates the archive.

You can see the job result here :

https://gitlab.com/prokopyl/gambas/-/jobs/29620075

(Warning : Big ./configure log, expect your tab to freeze for a bit !)

On the right panel you can browse the Job artifacts, and see it generated  
the
.tar.bz2 archive as an artifact you can download.

Unlike the repository source archive, Job artifacts are not meant to be  
directly
downloaded by the users, as anyone in the group can delete them wile  
cleaning up
(they do not expire by default, but we have a 10GB job artifact limit if I  
remember
correctly).

However, you can configure the pipeline to automatically upload the source  
package
to any server you'd like (using SSH, FTP, or anything that has a CLI  
really).

Something I would also like to setup later, is a Pipeline that checks the
configuration/build on several Linux distributions on every commit. Since  
the
Pipelines can rely on Docker, we can basically check for most major x86_64
distributions (and I think we can use qemu for other architectures, like  
x86
or ARM).

But that's just an idea, for now. :-)

-- 
Adrien Prokopowicz




More information about the User mailing list