← Back to team overview

yade-dev team mailing list archive

Re: Migrating to GitLab

 

Hi there,

The repository is functional at:
https://gitlab.com/yade-dev/trunk

For using gitlab you can read the updated doc page
https://yade-dev.gitlab.io/trunk/github.html#yade-github-label

As soon as you have a gitlab account let me know your login name so I can add you to the project.

I just discovered a technical constraints which makes MR from personal repo awkward at the moment (although it could work with future gitlab versions maybe [1]). The issue is that if a MR is generated from a forked repo to the parent yade-dev/trunk repo, then running the pipeline [3] requires that runners[2] be available in the forked repo. It is not possible to build the MR on the parent repo. So unless you have the computational ressources and enough skills/IT support to configure runners locally, MR from personal repo will not be tested automatically. They can be handled (some MR could still make it that way) but it is not very convenient and it will take more time to be accepted.

It is pushing us toward a solution closer to what Janek suggested, which was based on multiple branches more than multiple repos. I.e. push (normal push) to different branches of yade-dev/trunk, then MR from that branch to master. Since both branches are under yade-dev the group runners will be used in this case.

Please check the doc and let me know if some information is missing.

I suggest to not conclude migration before Anton's freeze.
You can still work with github repo if you have local changes and you are affraid to mess up, I will merge gitub repo into gitlab if needed.
Else please consider pushing to gitlab any future revision.

There is an experimental repo at https://gitlab.com/yade-dev/trunk-exp. Feel free to break it.

Cheers

Bruno


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/23902
[2] hardware on which compilation and regression tests occur
[3] https://gitlab.com/yade-dev/trunk/pipelines (you can click on every step to visualize process like https://gitlab.com/yade-dev/trunk/-/jobs/147313249)

On 1/13/19 10:03 AM, Anton Gladky wrote:
Hello Bruno,

thanks for the explanation. That is more-less clear. From my side - OK.

  would like to have you in the maintainers group if you agree.
Yes, I agree. Thanks.

Best regards

Anton

Am Fr., 11. Jan. 2019 um 14:53 Uhr schrieb Bruno Chareyre
<bruno.chareyre@xxxxxxxxxxxxxxx>:


On Thu, 10 Jan 2019 at 21:40, Anton Gladky <gladky.anton@xxxxxxxxx> wrote:
Sorry guys, I still cannot understand, what brings:
- renaming master->develop
- having potentially broken/not-mergable experimental branch.


Oh yes, it's confused. Things will become more clear with a functional repo (I'm only waiting for runners to be assigned presently, then we can switch).

Master took the name "develop" in the course of this discussion because of the master-develop framework mentioned earlier (by Janek).
If we keep a single branch there is no reason to rename it. It will be master.

Experimental: my intention was to let people play with an experimental gitlab repo so they can learn a bit of gitlab CI without messing up yade history.
Of course they can play with git in their personal repo but the cycle will be incomplete if they are not assigned runners. Hence why I suggested a draft project, perhaps only in a transitory phase.
There is no added complexity, it's just a clone of the main repo with runners assigned (we will not assign runners to each other personal repo, I guess it goes without saying).
If kept in the long run then maybe experimental repo could help sharing experimental stuff through precompiled packages without interfering with main repo.
Say, someone finds out that pink-colored GUI is better and he wants others to try it. If it's in experimental others can simply apt-get install to inspect the achievement.

Anyway, I am not so active in the project, so feel free to make your own
decisions. Do not forget to keep simple things simple...

I would like to have you in the maintainers group if you agree. And thanks for comments, they are helpful.
Cheers

Bruno


Regards


Anton

Am Do., 10. Jan. 2019 um 20:16 Uhr schrieb Janek Kozicki <janek_listy@xxxxx>:
OK, I think I finally understood your intentions:

merge requests go to develop (renamed from master), with several devs
approving it with www interface.

experimental branch is not used for that, but for whatever wild stuff
comes into mind.

This way Jerome needs not to worry, and everyone is happy :)




Janek Kozicki said:     (by the date of Wed, 9 Jan 2019 15:24:18 +0100)

Anton Gladky said:     (by the date of Tue, 8 Jan 2019 20:45:15 +0100)

Hi Bruno,

Anton, do you have comments on MR on Gitlab interface? Do you
confirm that they are a must?
Yes, definitely must have! As I told already each merge request can
be checked automatically by CI and reviewed by other developers
(with "approve"-technique).
very nice! I didn't know about this before.

I will have a look at that API which you mentioned.


I am fully support the feature-branch + merge request way of
working. It can really help to double check the code and implement
some additional tests.
So I am trying to wrap my head around this. We would have:

--------------------------------------> other people's feature repos
                              \
------------------------->    \         other people's feature repos
                     \MR        \MR
--------------------------------------> experimental
       \   /   \   \       /      /
--------------------------------------> develop
    \                    \
     \                    \
      \Release 1           \Release 2
       \Release 1.1

?

Bruno Chareyre said:     (by the date of Tue, 8 Jan 2019 17:50:02 +0100)

I would propose develop+experimental for a start, with release branches as
in Anton's picture.
So that would mean: rename master to develop, and create experimental?

Very liberal config for exp, and conservative for dev (even very
conservative initially, we will see if it is too conservative).
exp will *not* merge to develop, it will diverge progressively, most
likely, but it is not an issue. It can be re-synced. No commits can be lost
since by definition a MR to exp is from somewhere.
in other mail I only mentioned a nice method of solving conflicts.
Here let's focus on how you see that it should work. Especially I am
not sure what you mean by:

"exp will *not* merge to develop, it will diverge progressively, most likely"


Jerome raises a very important question: where do you merge request to?

Jerome wants to stay away from experimental and do merge requests to develop?

It means that it eliminates the buffer (in my previous posts it
was a buffer between develop ↔ master, according to Bruno's naming
suggestion that would be a buffer between experimental ↔ develop)
which I was proposing.

Do we want this buffer?


--
Janek Kozicki

_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

--
Janek Kozicki                               http://janek.kozicki.pl/  |

_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp




Follow ups

References