I was wondering if there was a way to get a list of errors when OctoPack is trying to package up my solution?
I have several websites with thousands of files. When I try to build one of the sites I get an error saying OctoPack could not find a specific file. I fix the file and try again. Rinse, Repeat.
Is there a way I can get OctoPack to give me a full list of all the files that I will have an issue with so I can go into my solution and fix the issues all at once. Going back and forth is very time consuming.
Thanks for getting in touch! My understanding is it doesn’t work this way. When it encounters an error, it spits out the message and then stops. So when you fix the cause, it proceeds further the second time, finds the next one and stops. There is no way to force it to continue through and give all the errors once it has encountered one.
What kind of fixes are you needing to provide your files? Is it a standard .NET website?
Yes, it is a standard .NET website. Basically we have many developers working on a bunch of sites. A lot of the assets are included in our csproj files. With these being included in the project file will tell OctoPack what to package. The problem is some developers do site cleanup (delete files) or accidently move files around outside of the project but don’t always update the project file. There could be a few hundred changes that we would have to search for.
What would be nice is if OctoPack would still fail because of packaging, but only fail at the end of the process not in the middle of the process and give a single error. Or, something that could also be helpful is an OctoPack project scan. This could just scan the project and identify where there would be issues when the packaging occurs.
Since when we compile the site we don’t have any compile issues because most of them are asset files.
Thanks for the extra info. OctoPack as a pack solution is best with not many hands when running manually otherwise it’s best after a build server has run such as TeamCity.
OctoPack relies on MSBuild, so you are running in to these issues. However there are two other ways to pack such as octo.exe pack and point it at a directory - but you will get files you probably won’t like, or Nuget.exe pack and define a NuSpec but then the NuSpec needs to be maintained.
In regards to “best with not many hands”, what do you mean by this?
As part of my automated build process (and I am using TeamCity), we set RunOctoPack=True when running MSBuild against our solution. The only reason we would run it locally (On a dev system) is to catch any issues we would have as part of the OctoPack system.
I have since created a PowerShell script that will go through our csproj file and validate that each file that is flagged for content and compile do exist. This gives me a report of all the files that are included in the project but do not exist on disk. As it turns out this works rather well, except for some of the files that it finds are not actually flagged as part of OctoPack.
Would you be able to provide me with the criteria as to what files OctoPack deems to be packaged and what it does not?
This would help me in refining my powershell script to better pair with our OctoPack deployment.