Hmm, looked at the shipit code and found this: https://github.com/shipitjs/shipit/blob/master/packages/shipit-deploy/src/tasks/deploy/fetch.js#L22-L26

So, shallow clone makes workspace irrelevant, why is this?

The workspace command was misunderstood, so I decided to set it to a temporary directory if shallowClone is activated. Why would you like to specify a custom workspace with shallowClone?

Well, mostly for reliability and flexibility.

I understand my scenario is a little unorthodox, but what I'm doing is I'm pushing the frontend code to a different server using ssh-pool (can't really use roles for that) and so at a certain point in time I was looking at the workspace for that... turns out, it's not there, even though the documentation states otherwise.

I've managed to work out a hack in the meantime, which acts before workspace is deleted, but it took me a while to understand it was shallowClone causing it (no documentation about this). I kept believing shallowClone was just about the shallow mode while git fetching, never expected to change workspace settings - worse, it doesn't change shipit.config.workspace so there is no programatic way to access that weird temp folder that's being created.

In any case, regardless my opinion - that not respecting the workspace setting is just bad logic - I think that the current behaviour should be documented. I would have been happy with just that 👍

I encountered the same issue and I have to confess this change is making everything so confusing...

I need to clone my code, cd into it and do npm install etc... how am I supposed to do this? if I set shallowClone to true (since I don't need to clone all my repo history, last commit is fine) it seem's there no way to know where the code has been cloned. If I set shallowClone to false I have to make sure the workspace directory exists before cloning.

what's the "official" way to clone a repo, do some operations on the file and then copy the resulting files to the server?

@cvlmtg the way I'm working around that is by listening the init event and mkdir the workspace dir:

    shipit.on('init', async () => {
      // This is due to a bug on v4.0.2:
      // https://github.com/shipitjs/shipit/issues/185
      logInfo('Performing a hack...', shipit);
      await shipit.local(`mkdir -p ${LOCAL_WORKSPACE}`);
    });

Regarding the shallow clone issue, I've laid out my thoughts above but there's something else that isn't quite working which is the shallow clone isn't being applied to submodules. For this to work I'm also using a hack:

    shipit.on('fetched', async () => {
      await shipit.start('submodules:fetch');
    });

    shipit.blTask('submodules:fetch', () => {
      logSuccess('Cloning finished. Fetching submodules...', shipit);

      const data = {};
      return shipit
        .local('git config -f .gitmodules submodule.3akai-ux.shallow true', {
          cwd: LOCAL_WORKSPACE
        })
        .then(() => {
          return shipit.local('git submodule update --init --recursive', {
            cwd: LOCAL_WORKSPACE
          });
        })
        .then(() => {
          logSuccess('Check-out finished. Setting up 3akai-ux...', shipit);

☝️ Just in case it helps anyone reading this.

@brecke thanks for the help! I've been able to solve my problems this way:

1. I changed dirToCopy from an absolute path to a relative one
2. I no longer specify workspace in the options
3. instead of reading it from shipit.config.workspace I read it from shipit.workspace. this is something which I discovered looking at the source code you linked, otherwise I had no idea it was accessible from there, I can't find any documentation regarding this attribute...

then I had to add a mkdir -p ... before compiling a template I have to upload to the server, because workspace is wiped away before the deploy finish completely, but that was a minor issue :)

because workspace is wiped away before the deploy finish completely

☝️ this should also be turned into an option, I've had to work around this myself. It's not documented and I'm not given a chance to avoid default behaviour.

I think we should make it optional, if workspace is not defined do not use it and let user the choice to define one. Anyone is interested by submitting a PR for it? If you do, don't forget tests and documentation please 🙏!

@neoziro not sure if I'm up to the task, but the problem, or at least my problem, is that the concept of the workspace is unclear, and the documentation is lacking.

what's the purpose of the workspace? why do you say it was misunderstood? what should it do? how was it supposed to be used? why shallow clone ignores it? etc...

before adding other options I'd try to improve the doc, but as I said it is not clear what was the original idea behind the workspace and how it was supposed to be used or defined etc...

The workspace is actually the directory which is used to clone the repository before deploying it. But most of users was setting it to an existing directory, like the current project and it was erased. To avoid it we can do several things:

• Use a temp directory in shallow (already done)
• Check that it is not the current directory
• Warn in documentation about it
• Being able to specify a workspace in shallow mode

Actually only the first one is done, so if you are up to the task, you have the three others to do!