We started using ProGet to host our packages. With our project still being in the early development phase we push packages often to our server. Our team is very distributed over the world so the pulling of packages to local computer is very important. We have noticed when we do a Nuget.exe -Update on a project and it pulls down the package from the server, it downloads the complete version xml list. On average that XML file is already between 300-550kb per package and growing by the day. Now we've been on ProGet for about 6 weeks, and with this growing in version XML file size it is going to be a real problem .
I have noticed that when we run the update that the "Microsoft*" packages all of them the "body length" in Fiddler is all around 461 bytes, and the body only contain one version.
Our package in the other hand the body in Fiddler contains all the versions from day one. Are we using ProGet wrong, or maybe a setting somewhere?
Related
I am in the process of migrating to the latest version of ProGet. I'm currently using version 3.8.6, so am quite far behind the stable release.
I decided to start fresh, moving to a brand new Windows Server 2016 box in AWS, and using RDS for the SQL database.
The new setup is working perfectly, I have imported our NuGet packages by creating a feed, entering a Drop Path and dropping all of the packages there. ProGet picked up on this and moved them all to the Feed.
However, I am now trying to import our npm packages. I've created the feed, added a drop location and moved all the npm packges over. On the old server, they're all already in subfolders. ProGet seems to refuse to add them unless they're in the root folder specified as the Drop Path. So I've moved some packages there (inconveniently they're all called package.tgz...) and it picks them up, moves them to /ProgramData/ProGet/Packages/.npm/F5/ puts them in folder too but then does not become visble in the feed on the web interface.
The package number increases, and if I click packages I can see them all, then click into them and download the package, but it doesn't show up on the main Feed 'Page'.
On the other hand, if I manually upload a package via the web interface, it doesn't put the packages in the same location as above, but it is visible on the main feed page... Is this a bug or am I doing something wrong? The NuGet packages work perfectly using the same method, so I'm confused as to why npm isn't working.
I noticed this same behavior when using the bulk upload utilizing the drop path. From what I can tell, you must have at least one version with the "latest" tag on the details for it to show anything in the Feeds view.
Version 2.8 of NuGet server now provides a flag in the web.config called allowOverrideExistingPackageOnPush which allows you to decide if you want existing package versions to be overwritten. We decided to set this to false on our internal repository because we didn't want existing packages being accidentally overwritten. However, now when I do a pack and push using the -Symbols flag, the push command will successfully publish the nuget package but when it tries to publish the symbols, it only uses the first part of the package name up to the end of the version number. This means that it fails to publish the symbols package as it believes that the package already exists.
I have yet to find any information or bug reports via googling, and for the package I am writing now I can dispense with symbols, but we need a longer term solution which will allow us to publish symbols and disallow overwriting.
Has anyone encountered this, and if so have you found a way round this (other than not publishing symbols or allowing overwriting)? This has been sapping time which I can't really spare.
I had downloaded cygwin from one mirror site, and after a few months when I try to update now I get the message that the "current ini file is from a newer version of setup-x86_64.exe"
If I download a new ini file, does it also mean that the entire cygwin installation will have to be downloaded again? That will take a huge time and I would like to avoid it.
Also, what is a stable mirror site for cygwin? On some update occassions, I have got the message that the site is no more a "recommended" site, and I should select another mirror site.
The answer to your main question is NO. That message appears because the setup-x86_64.exe file has been updated. You need to download a recent version at http://www.cygwin.com/setup-x86_64.exe.
Mirror sites are updated on a schedule, so the updates at mirrors are always behind the main Cygwin site by a certain amount. Some sites update more frequently than others. From the Cygwin mirror admin site:
Given the granularity of checking, it is possible that your site will
be polled after a package update on cygwin.com but before your site
has pulled the update. So, it is expected that from, time-to-time,
your site may fall off the mirror list temporarily. If your mirror
site has not been listed for a day or so that means that some cygwin
packages on your site are not current. Check the cygwin-announce
archives for announcements about recent package updates and ensure
that your site has those packages. Once your site has the recent
packages it will be re-added automatically.
and
So, if your site was dropped from the list it means that a program has
determined that the files on your site are not up-to-date. Unless your
site has been out of date for (currently) 100 runs of the program, it
will be re-added automatically when it becomes current. So, if you see
that your site has been dropped from the mirrors list do not panic.
I’ve generally found that unless you repeatedly get the message about it not being a recommended site, there's nothing to worry about, just try again in a few hours or the next day. Picking the site closest to you is generally a good bet.
You just need to download a newer version of the setup.exe file and perform the update with that.
During the setup you'll be presented with a list of recommended mirror sites, choose one near to you and you're good to go.
No worries. :-)
How can I create a CentOS 5.8 .iso image with custom packages? I have to create an iso with only the packages needed for our production system. I already have all the rpms with their dependencies resolved in a folder. I have successfully created a repository from that folder with createrepo.
As I understand it, I should put the rpm files in the CentOS folder, and repodata folder should contain the metadata needed for a package manager. I don't know if I should modify the existing comps.xml file or create a new one, or which structure to use, since this is only a subset of packages contained on a default CentOS installation disk.
I know it is probably futile to delete packages from the default iso, but that is my work order and there's not much to be done there. (There are also some packages not available in the default iso)
Much appreciated
I feel as though your question is a bit vague for a topic with this sort of breadth but I'll do my best to offer an answer. I think you should use Kickstart for this task as it's going to result in a much happier customer whether they're internal or external, and easier management for you going forward when things get updated. Start by reviewing the CentOS documentation, if you are already this far and just asking about removing packages, check out this section of the docs, it talks about specifying your packages and removing the ones you don't want.
If you only have the one style of production machine, then this should take care of it. if you have multiple different configurations I'd suggest taking a look at a configuration management tool such as Ansible, Puppet, or Salt. This would allow you to provide a base image via Kickstart, then build off of that image depending on the needs of whoever is consuming the system.
I want to clear out the working directory in a CruiseControl.NET build after the site has been deployed because space is an issue and there's no requirement to keep it.
The way things are set up at the moment everything is on 1 machine (that's unlikely to change), this is acting as both Mercurial repository server, testing web server and CruiseControl.NET build server.
So on C:\Repositories\ and C:\inetpub\wwwroot\ we have a folder per website. Also in C:\CCNet\Projects we have a folder per website per type of build (Test and Live) - so that means we've got at least 4 copies of each website on the server and at around 100mb per site X 100 sites that's adding up to a lot of disk space.
What I thought I would like to do is to simply delete the Working Directory on successful build, it only takes 5-10 seconds to completely get a fresh copy (one small advantage to the build server being the same machine as the hg server) and only keep a handful of relatively active projects current. Of the 100 or so sites we'll probably work on no more than 10 in a week (team of 5).
I have experimented with a task that runs cmd.exe to /del /s /q the Working Directory folder. Sometimes this will complete successfully, othertimes it will fail with the message that "The process cannot access the file because it is being used by another process". When it does complete ok the build kicks off again, presumably because the WD is not found and it needs to be recreated, so I'm finding I'm in a never ending loop there.
Are there any ways I can reduce the amount of space required to run these builds or do I need to put together a business case for increasing hosting costs for our servers?
You need to create your own ccnet task and build the logic into it.
Create a new project called ccnet.[pluginname].plugin.
Use the artifact cleanup task source as base to get going quickly
Change the base directory from result.ArtifactDirectory to whatever you need it to be
Compile and place \bin\Debug\ccnet.[pluginname].plugin.dll to c:\Program Files\CruiseControl.NET\server or wherever CCNET is installed.
Restart the service and you should be able to use your task in a very similar way as the artifacts cleanup task