Skip to content

Checkout parent repository when submodule depends on it. #484

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
AraHaan opened this issue Apr 26, 2021 · 0 comments
Open

Checkout parent repository when submodule depends on it. #484

AraHaan opened this issue Apr 26, 2021 · 0 comments

Comments

@AraHaan
Copy link

AraHaan commented Apr 26, 2021

Currently one has to do this within a subproject in order to build it if the subproject requires files from the parent project to be cloned first

https://github.com/Elskom/zlib.managed/blob/main/.github/workflows/dotnetcore-build.yml#L15-L24

However doing this (since it's .NET Core) if the project uses source link, it would result in various warnings when building saying it cannot read the .git directories of the clones.

A cleaner aproach to this I would prefer more than this would be a simple actions/checkout@v2 step that then sets
parent: 'Elskom/Sdk'

So then the checkout action would look at it (default to that is null), and if it's not null or empty, check it out first, then check out the other repository like normally.

Something would need to be done on this action to somehow fix sourcelink's complaining though.

Bonus Points: Do not emit this to <subproject repo name><subproject repo name>/<parent project repo name> and instead of <parent project repo name>/<parent project repo name> at least.

The reason why as to this is an issue as it wastes valuable build time doing them separate and then it tries to clear out the specific directories that are being cloned too.

Alternatively, in this case the action could recursively clone the parent, then check out the commit to the subproject like normally and avoid the clear out on it in terms of the files, however it would mean also adding a variable to tell the action where the submodule is located at in said project so it can check out the commit of that specific project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant