--recursive-submodules on runner pull step?

[BoogieManTM]

I've got a patch in my fork of semaphore that I found to be critical for our usage. We're using git submodules for inventory management, and found that while the repository is cloned, --recursive is used. Which is great, but those submodules can quickly get out of date and once the repository is cloned, the pull step to update the repository does not recurse the submodules.

I realize this is a relatively modern feature in Git (introduced sometime in 2.x), but we've already had to update git just to get the SSH keys to work. I'm not sure what the minimum version required of Git to get keys to work, so I can't say if this is much more bleeding edge than what is already required to function fully.

Another option would be to force a full clone of the repository every run. A "Fresh repository checkout" kind of option, but seems much more aggressive than my proposed changes.

And finally, an "optional git arguments", similar to the playbook arguments for specifying an inventory, would also work for us since --recursive-submodules seems to work on any git verb semaphore is using currently.

Thoughts?

[twhiston]

FYI The plan for the next version of semaphore is to move to the pure go git implementation https://github.com/src-d/go-git so we will be a little tied to their feature set but this should be possible. There was also some discussion about this already on #501 as altering a playbook whilst another task is in flight may cause undefined behavior, so we need to think about it a little. Do you have a link to your patch or can you make a PR so we can discuss it with the change in front of us?

[BoogieManTM]

My change can be found here: https://github.com/BoogieManTM/semaphore/commit/d55817eb95a2b91fa459ea411aab2a4e6eba9746

Looks like go-git already supports recursive submodule pulls, so that implementation should work beautifully without forcing a relatively bleeding-edge git client. It's one of the PullOptions for WorkTree.Pull(). Is there a branch of Semaphore already using go-git I can try for testing? Or has that work not started yet?

[twhiston]

unfortunately nothing to try out yet, it's on the roadmap for 2.6.0 so I'll probably start it soon.

[kumy]

I'm not sure what the minimum version required of Git to get keys to work

For references, GIT_SSH_COMMAND was introduced in git 2.3.0.

We are also relying on submodules and we need to update them manually when they are updated :/ Is it possible as a quick win to have them updated with the current code base (ie; not waiting "[…] the next version of semaphore is to move to the pure go git implementation")?

[neo1908]

Hi,
Is there any plans to look at this in the near future? I've just got started using semaphore and ran head first into issues with git submodules.

I'd be interested in helping out with porting to go-git if that is still the plan

[Ereaey]

GoGit was integrated a while ago.
Any idea if the change is planned soon ?

[Aaron-von-Awesome]

Is there a workaround for this? Or this on the roadmap?

[CappuccinoCake]

Hey, is there any update on this issue, as I am using also submodules for my roles in ansible. Would be nice if there is a solution, or a date for a planned feature to solve this problem. Because atm the feature of submodules is relative unusable because you have to update them manually every time... Thanks in advance.

[stafwag-fod]

Hi,

I'm looking into having smaller releasing components with semaphore ( I will probably start a discussion about it and link it to this issue ).

It'd help to have git submodule support within semaphore.
It'd be nice if the developers can let us know if this is on the roadmap. 

[stafwag]

Hi,

I'm looking into having smaller releasing components with semaphore ( I will probably start a discussion about it and link it to this issue ).

It'd help to have git submodule support within semaphore. It'd be nice if the developers can let us know if this is on the roadmap.

Opened a dicussion about this topic: #1941