Config as code- path too long

When initialising config as code between an already established Octopus Project and an existing GitHub Repo, we’re getting “‘C://P25MUQG4DNTWWAR2UZICNPJ6MRJKJAWV/b22UGEAJ2IWO4NIQB5KMLVMAOB2ENVKW6//Service References/’: The filename or extension is too long.”
The total file path length is 280 characters, and Git has a limit to 260 characters in Windows. Unfortunately, we’re limited in our ability to shorten the path as we can’t control the long Service reference file names.
Whilst this isn’t an Octopus bug per-se, the long generated path names that it uses are certainly a contributing cause- it’s adding 60 characters beyond what we normally use.
As a result, Config as Code fails to initialise.
Would it be possible for you to shorten, or have the ability to specify a folder name where the git repo is cloned?

Hi Mark,
Glad to see you are most of the way there with the Config-as-Code with the previous ticket.

I’ve run this issue by our Config-as-Code team and they came back with some feedback:

What these paths are
The first path is for the specific repository, the second is for the specific commit, tag or branch. They are the size they are to help us avoid any potential collisions where two repositories end up with the same path.
Potential option
We could add a user-specific option to shorten the paths but then we increase the risk collisions. That’s still just a mitigation, and paths might end up getting longer and breaking it again. It might be able to buy us some time and get some folks out of a bind if necessary. We’ll look to see what we can do.

I’m chatting with the team now to see what’s the best way to get you up and running.

Kind Regards,
Paraic

It would be nice to be able to allow the user to specify the path name (perhaps defaulted to the generated path), and for the user to be responsible for any path conflicts

Good afternoon @mark-qds,

Just jumping in here for Paraic as he is currently off shift as part of our Australian based team. We have had a few customers reaching out about similar issues to this and they have requested the ability to specify path names too, our engineers have looked at ways of making this easier for users and some things are in the works but may take awhile to reach the build stage.

I did relay your query about having the user specify the file path and making them responsible for any path conflicts so hopefully they see that and take this on board.

The engineers are aware of the other users and what got them up and running was creating a new separate repository to store your files in for now, whilst we realise this is not the best option it did allow their projects to be converted over and deploying correctly. We think this is due to that new repository not having historical data and therefore not as long file names are generated.

It looks like the engineers are going to create a GitHub issue for this which will go into a bit more detail and give you some workarounds (though the main one will be the new separate repository).

I will update you if there is any movement on this and if a GitHub Issue does get raised we will post it in here for you so you can subscribe and follow along with the updates.

I know this is not the news you wanted to hear but it does look like the engineers are taking a deeper look at this for our customers so hopefully we can produce some better workarounds for you all soon.

If there is anything else you need in the meantime please reach out,

Kind Regards,

Clare Martin

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.