Submodules

[scttnlsn]

Submodules are currently ignored during deployment. Once Rugged implements submodules (libgit2/rugged#246) consider including them as part of the deployment.

[jtsternberg]

Looks like submodule support got into rugged: libgit2/rugged#408

[jtsternberg]

Just throwing that in here as I would really like to see submodule deployment support. :)

[pruett]

👍

[jtsternberg]

@scttnlsn Curious if you've had any thought towards incorporating submodules to the deployment?

[scttnlsn]

@jtsternberg I don't have the need for submodules myself at the moment so I probably won't get around to implementing them anytime soon. Pull requests are welcome!

[jtsternberg]

@scttnlsn I fully understand that sentiment! I may try to get my hands dirty if I ever a) get the free-time, or b) have the dying-need. :)

[bobrocke]

👍

[TheLonelyGhost]

If we can spec out the use case for submodules, I may spend some time working on it.

I'll kick off the discussion. How should we track the deployed version of each submodule? Should it be part of the same revision file as the main repository, or should each submodule contain its own copy of the revision file in a separate location?

[bobrocke]

I'd say separate, in the same way that Git keeps a separate .gitmodules file.

[jtsternberg]

Agreed. Separate.

[bobrocke]

Have you gotten enough feedback to proceed? I, for one, am looking forward to sub-module support.

[scttnlsn]

Yeah, I think separate files would be best. I'm wondering if it makes sense to just store a .revision file in each submodule directory on the server. Dandelion can detect if a given local path is a submodule and read the corresponding remote revision.

Here's some initial work I did to gracefully ignore submodules: https://github.com/scttnlsn/dandelion/tree/submodules

Previously it was raising an exception that @bobrocke was running into (#128).

[TheLonelyGhost]

@scttnlsn That's what I was thinking too, but it would require further HTTP server rules forbidding access to .revision if it ends up in the doc root. I find that manageable but not sure if everyone else does.

What about how we want to deploy the submodules? I assume we'll recurse into each submodule directory, but how do we control the version specified with dandelion deploy [commit-ish]? If we have an application at v3 (most recent version is v4) and it depends on other sub-modules at specific versions, this breaks dandelion deploy [commit-ish], doesn't it?

Do we want to limit deploying with submodules to the currently checked-out commit regardless of specified commit-ish above?

[TheLonelyGhost]

Apologies, I'm less familiar with submodules than nested git repositories.

[scttnlsn]

@TheLonelyGhost Those are all great questions. I don't personally have a use case for submodules so it would be great to hear from others who want this feature about how they intent to use it.

Another way I could see implementing this is forcing users to pin the submodule version that they want deployed (probably in a submodules section in dandelion.yml). The downside here is that updating a submodule in the working tree would not necessarily reflect what is deployed (unless the submodule revision was also updated in dandelion.yml). I think I would personally find this less confusing than just deploying whatever revision happens to be in the working tree.

Curious to hear from others.

[bobrocke]

I'm not sure what nested Git repositories are, or how they may differ from submodules.

When I make an update that effects one or more submodules, I would expect the the submodules' changed files are uploaded along with whatever changes exist in the base repository. Each submodule has its own .git folder, show there should be a way to do the uploading recursively.

[bobrocke]

Is this improvement still coming?

[scttnlsn]

@bobrocke I just pushed 0.4.11 which will now gracefully ignore submodules. This will allow you to deploy submodules as separate Dandelion repositories. There's still more work and discussion around having Dandelion deploy submodules automatically.

[scttnlsn]

Actually, use 0.4.12 now.

[bobrocke]

@scttnlsn Thanks! That's an improvement.

What must be decided for automatic deployment?

[TheLonelyGhost]

Since I last posted I've had more of a chance to actually use git submodules. Now I know that a submodule (git repository) has the currently checked-out commit versioned in the parent's working copy as if it is another file. This reduces a lot of the complexity from my perspective.

The main question I have is how to hook into the submodule functionality in Rugged. Haven't had much experience with native ruby extensions unless they were well documented and I don't see much on submodules there...

[TheLonelyGhost]

Note, this is likely on hold until #129 (problems with Rugged v0.22.2) is resolved. Submodule support was in the Rugged update.

[bobrocke]

Any progress to report?

[TheLonelyGhost]

Since #129 is resolved by sticking with Rugged v0.22.1b1 and that version appears to contain the merged pull request from libgit2/rugged#475, it appears this is greenlit for development again.

As for progress, none so far on my end. Unable to devote time to this at the moment with my work schedule. I still see several big obstacles in implementing this, but the biggest would be lack of documentation for rugged. I haven't looked into the branch for this that @scttnlsn started since it was mentioned above, but it might be of more help than I realize.

Would definitely be available to review a pull request if someone wants to take a stab at this.

[dionysiusmarquis]

+1