Skip to content
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

mv: ‘../current/log’ and ‘../vserver/log’ are the same file #47

Open
runkelstein opened this issue Mar 24, 2021 · 6 comments
Open

Comments

@runkelstein
Copy link

runkelstein commented Mar 24, 2021

Hello Everyone,

I upgraded to stork v3.0.0 after moving to java11 for a new project.

The first deployment worked, however now after the second deployment the following error occurs:
mv: ‘../current/log’ and ‘../vserver/log’ are the same file

Can someone please advise me how to fix it?

@runkelstein
Copy link
Author

I think that only the timestamp in the folder name is missing. In stork 2.x there were folders which did hold the content of different deployed version and so there were folders like "vserver-20210318-145717". And this is what is missing on my new installation. So I think what may happen is, that the new data gets copied to the same folder as the previous deployment and therefore the old logic fails.

Could be my configuration or a bug.

@runkelstein
Copy link
Author

runkelstein commented Mar 24, 2021

In the document it says that the timestamp is only generated if it is a snapshot version?

"Since this a "SNAPSHOT" version, a timestamp would be generated (such as 20160401-121032 for April 1, 2016 12:10:32) and this application would be installed to:"

Okay so does this mean that the file (service.tar.gz) needs to incorporate the version number, since this is also part of the folder name?

Furthermore actually since I'm deploying a snapshot version it should work? Where does the information come from?

@runkelstein
Copy link
Author

Okay if the file assembled file name is like "service-SNAPSHOT.tar.gz" the folder with a timestamp gets created.

I hope it works if I put in semantic version numbers as well, that would be awesome

@runkelstein
Copy link
Author

runkelstein commented Mar 24, 2021

So now I played a bit with it and used semantic versioning.

And unfortunately it did not work the way I expected. So far I can only test with snapshot versions.

So we have a version like "21.14.0-beta-SNAPSHOT" for our dev branch. On stage it would be "21.14.0-SNAPSHOT" and on live it would be "21.14.0" or after a hotfix "21.14.1"

Now when I deploy with a file called "server-module-21.14.0-beta-SNAPSHOT.tar.gz" it will create a folder like
/opt/company/server-module-21.14.0/vbeta-20210324-080839

But when I deploy "server-module-SNAPSHOT" the folder will be called
/opt/company/server/vmodule-20210324-080839

So now that I unterstand how it is working, I know that only the last two columns (separated by the -) will be considered as version number.

I can rename that file accordingly, the mechanism how it works is just confusing.

Also all of these versions are valid maven versions, in case you are wondering.

@runkelstein
Copy link
Author

runkelstein commented Mar 24, 2021

<final.jar.name>server-${project.version}</final.jar.name>

How do I get the version number into the folder name as well?
like this?

/opt/company/server/v21.14.0-beta-20210324-080839

I suppose live it is working, since the version number is less complicated there.

@runkelstein
Copy link
Author

I think I will just use differnt profiles in maven for dev, stage, live

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