Le Wed, 16 Aug 2017 23:14:54 +0200, Benoît Minisini
<gam...@users.sourceforge.net> 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@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
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
