drone-cli copy current workspace (git repo) to temporary directory instead of directly operate on current workspace

[stevenleeS0ht]

According to https://docs.drone.io/quickstart/cli/#local-vs-remote

drone-cli will directly make current working directory as a docker volume for the CI container.

However, this kind of behaviors may make current working directory messy.

I strongly suggest make a new directory which is going to become the volume of CI container, and simply copy the current working directory recursively (all the sub-directories and files.) to there.

If don't like ignored files, simply git clean -xdf, or just move files which is in git ls-files.

This would make drone-cli much more like as drone remote environment.

[stevenleeS0ht]

@bradrydzewski , what is your opinion?

[stevenleeS0ht]

Or if just want git repo instead of workspace, just copy .git folder to target directory, and apply git checkout command after copy is done.

As far as I see, file coping, can cover 100% of behaviors what remote CI server with git init . && git remote add xxx xxx && git pull or git clone xxx, since git is distributed SCM.

[stevenleeS0ht]

But I would like to recommend that copy the workspace to target directory instead checkout inside the target directory, because directly coping files is much faster than checkout.

And plus the current version of drone-cli directly make operation on current working directory. That means Git SCM feature doesn't play a important role in this scenario.

[stevenleeS0ht]

@bradrydzewski , more strictly speaking, it is not "current working directory". It should be the root directory of git, which .git/ directory located at.

It would be awesome if drone-cli can provide ability to automatically correct the "current working directory" if current working directory is at this moment on the sub-directories. For example drone exec ../../.drone.yml.

Or just no ../../.drone.yml specified, because git can automatically locate .git/ no matter which sub-directory it is now located unless it is the directory outside the repo root directory.

If drone-cli can automatically locate project repo root directory, then it will be awesome.

[bradrydzewski]

I think it would be more prudent to make this optional and opt-in.

Please keep in mind that changing default behavior can have unintended, negative consequences for our existing users. In this case, there are teams using Drone to build artifacts in the working directory (see https://github.com/vmware/vic#building) and this is not something we want to break.

In addition, for large projects, copying the repository may take a long time which would degrade user experience.

For these reasons I would vote against changing the default behavior. However, I think adding an opt-in flag to copy the workspace to a temporary directory would be a nice feature. There is an existing pull request to optionally copy the workspace into a temporary directory that is no longer mergeable; I would recommend refactoring / resubmitting this existing pull request if you would like to see this feature in Drone.

The pull request to copy the workspace was never merged because the code to copy the directory was incomplete and had a number of edge cases (problems with symlinks, etc). So for anyone interested in resuming work on this pull request, I recommend using the copy function described in this stack overflow post or maybe use this library.

[stevenleeS0ht]

@bradrydzewski ,

Is behavior of drone strictly depend on git? In other word, will drone be able to work if the repo is not managed by git for example, hg or no scm tool.

For drone-cli, is it acceptable if add git or go-git package dependency?

Currently, you plan to remove the deprecated dependency and refactoring the drone-cli.

Do you think that the file coping feature is coupling with that planned refactoring?

[stevenleeS0ht]

@bradrydzewski , by the way, "described in this stack overflow post or maybe use this library.", the stackoverflow link is pointed at github/pullrequest.

Please, correct it.

[bradrydzewski]

Is behavior of drone strictly depend on git?

no, we cannot build a solution that assumes a .git folder exists or that git is available.

I think for me this proposal is a bit unclear and I am having trouble understanding. I recommend collecting your thoughts into a more comprehensive rfc (see this example of a comprehensive rfc) that clearly describes the problem, the goal, and the proposed technical solution, as well as alternate solutions considered and why they were not chosen.

[eoinmcafee00]

Hey @stevenleeS0ht I'm closing this issue due to not enough information provided.

Please feel reopen if you want to provide it.

Cheers, Eoin