Our internal Nexus repository has an artifact that we wish we never published, but unfortunately we did. And various environments installed it.
I'd like to delete it from the repository so that nobody downloads the erroneous release again, but for the people who already downloaded & installed that artifact, it seems a bit deceptive to pretend the release never happened. Is there a way to "archive" or "disable" an artifact so that it still is preserved somewhere for analysis or archeological purposes, but won't be installed by someone pulling artifacts for installation?
There isn't a feature in NXRM for disabling access to individual artifacts. This is a bit hacky but you could achieve it by
Creating a new hosted repository (either raw format or the same
format that you are currently using)
Marking that repository as "offline"
Moving the artifact to the archived repository.
Step 3 is the problematic part: If you are an NXRM PRO user on a recent version there are REST calls you can use for moving components. See here for more details https://help.sonatype.com/repomanager3/staging#Staging-RESTEndpoints
If you are an OSS user you will likely have to republish the same artifact to the archive repository and then delete it from the original repository.
(Note the above assumes you are using NXRM3 - if you are using NXRM2 take a look at https://blog.sonatype.com/2010/04/nexus-tip-moving-artifacts-between-nexus-repositories/)
Related
I'm having the same issue as nuget feeds and promotions, eight years later!
In this case I'm talking more generically; we're using ProGet as our package manager, and have nugets, universal packages, and even some docker containers to consider in the package promotion process.
One of the ideas is to have several Nuget feeds; a ci feed where every successful integration publishes a package, a qa feed that you only publish versions you want qa to test and then a release feed, where you copy only packages from the qa feed that they successfully tested.
So, say we have a build in the ci feed that works, it's version 1.2.3-ci-xyz. We want to promote that to the QA feed, without a rebuild, and re-package it as 1.2.3-rc-1. That package passes QA and is ready to be promoted into the prod feed, with no rebuild, and ship to production. It should ship as 1.2.3. (right?)
The question is, if we're not doing any rebuilds, the package binaries will still have the version 1.2.3-ci-xyz. That'll show up anywhere a version is displayed or queried in the app.
And that's where I get stuck. What's the proper pattern here? Does it matter what version is shipped, as long as we know what it is?
meaning, we promote 1.2.3-ci-xyz from lower feeds to higher feeds, without repackaging with different versions?
Wouldn't it be incorrect for package 1.2.3 to include a binary 1.2.3-ci-xyz?
do we always build with the next 3-digit number, and forget about the ci/rc suffix?
I'll share this answer from our internal support channel :)
This is how we (Inedo) typically handle this in our libraries. The short answer is:
We set the Assembly Version to Major.Minor.Patch
We set the Assembly File Version to Major.Minor.Patch.Build
We set the Package version to Major.Minor.Patch-ci.Build (we then repackage to Major.Minor.Patch-rc.Build then to Major.Minor.Patch)
We also use the Assemble Informational Version to display a friendly version (ex: Version 6.0.0 (Build 36-v6))
This allows us to repackage without rebuilding. We also will detect these pre-release dependencies during our product builds and prevent them from being released to production. You can see our ProGet v6 build as an example: ProGet 6.0.0 Build 36.
The longer answer I feel is answered pretty well in our blog post Best Practices for Versioning NuGet Packages in the Enterprise.
I have a python27 appengine application. My application generates a 500 error early in the code initialization, and I can inspect the stack trace in the StackDriver debugger in the GCP console.
I've since patched the code, and I've re-deployed under the same service name and version name (i.e. gcloud app deploy --version=SAME). Unfortunately, the old error still comes up, and line numbers in the stack traces reflect the files in the buggy deployment. If I use the code viewer to debug the error, I am however brought to the updated patched code in the online viewer -- and there is a mismatch. It behave as if the app instance is holding on to a previous snapshot of the code.
I'm fuzzy on the freshness and eventual consistency guarantees of GAE. Do I have to wait to get everything to serve the latest deployed version? Can I force it to use the newer code right away?
Things I've tried:
I initially assumed the problem had to do with versioning, i.e. maybe requests being load-balanced between instances with the same version, but each with slightly different code. I'm a bit fuzzy on the actual rules that govern which GAE instance gets chosen for a new request (esp whether GAE tries to reuse previous instances based on a source IP). I'm also fuzzy on whether or not active instances get destroyed right away when different code is redeployed under the same version name.
To take that possibility out of the equation, I tried pushing to a new version name, and then deleting all previous versions (using gcloud app versions list to get the list). But it doesn't help -- I still get stack traces from the old code, despite the source being up to date in the GCP console debugger. Waiting a couple hours doesn't do anything either.
I've tried two things:
disabling and re-enabling the application in GAE->Settings
I'd also noticed that there were some .pyc files uploaded in the snapshot, so I removed those and re-deployed.
I discovered that (1) is a very effective way to stop all running appengine instances. When you deploy a new version of a project, a traffic split is created (i.e. 0% for the old version and 100% for the new), but in my experience old instances might still be running if they've been used recently (despite them being configured to receive 0% of traffic). Toggling kills them all immediately. I unfortunately found that my stale code was still being used after re-enabling.
(2) did the trick. It wasn't obvious that .pyc were being uploaded. I discovered it by looking at GCP->StackDriver->Debug and I saw .pyc files in the tree snapshot.
I had recently updated my .gitignore to ignore locally installed pip runtime dependencies for the project (output of pip install -t lib requirements.txt). I don't want those in git, but they do need to ship as part of my appengine project. I had removed the #!.gitignore special include line from .gcloudignore. However, I forgot to re-add *.pyc into my .gcloudignore.
Another way to see the complete set of files included in an app deployment is to increase the verbosity to info on the gcloud app deploy command -- you see a giant json manifest with checksums. I don't typically leave that on because it's hard to visually inspect, but I would have spotted the .pyc in there.
In our current dev. workflow there is main database --> DbMain. There is the process that takes the latest version of the project and automatically deploys it there and after that it triggers unit tests. As we would like to always have working version of the project in the source control each developer should be sure that he checks in the working code and all tests would be passed.
For this purpose we decided to create individual databases for each developers that has following naming convention --> DbMain_XX (where XX are the developers initial). So every developer before the check-in is suppose to publish all the changes to that database manually and run the unit tests. It is useful to setup publish config for this purpose with that is the copy of the main publish config with the only difference in the database names.
That would introduce that we will have a lot of different publish profiles in the solution that is quite a mess.
If we will not add these profiles to the source control, then .sqlproj file would still have reference to these files so the project will have reference to the not existing files.
So the actual question. Can I have single publish profile for all developers where the database name will be changed using variables? For example DbName_$(dev_initials)? Or can we have that each developer would have their own publish configs only locally and it wouldn't break the project?
UPDATE:
According to the Peter Schott comments:
I can create local publish profile, but if I don't add it to the source control, then the still be an entry in sqlproj file, but the file itself will be unavailable.
Running tests locally have at least 2 disadvantages. The first one is that everybody is supposed to install SQL Server locally. We are mainly working via virtual machines and the disk space is quite limited there. Another thing is that developers will definitely forget or not will not run tests manually every time. Sometimes they will push changes to the repo without building it or/and running tests. We would like to avoid such situations and "catch" failed build as soon as possible.
Another approach that was mentioned is to have 1 common build database. And in my case we have one (DbMain). All of developers can use it for it's needs but we will definitely catch the situation when the 2 developers will publish at the same time and that can make a lot of confusion by figuring out what's really went wrong.
A common approach to this kind of thing - not only for SSDT publish profiles but for config files in general - is to commit a generic version of the file with a name something like DbMain.publish.xml.template, and provide instructions to the developer to rename the file to DbMain.publish.xml - or whatever - and .gitignore this local copy of the file, allowing the developers to make whatever changes they want, but inherit the common settings from the .template version of the file.
Publish profiles don't need to be added to the .sqlproj to be used at deploy time, this is merely a convenience in Visual Studio to make them easier to find and edit, so you don't need to worry about broken references.
You are right in wanting to avoid multiple developers publishing to a common "build" database, this is a recipe for frustration.
Really, you want the "build" database to be published to as part of your CI process, meaning after the developers have pushed their changes.
I'm thinking of a good deployment strategy for magento. I already have managed to deploy code with git from my local installation to my stage server. (The jump to live is not a problem then)
Now I'm thinking about how to deploy backend changes like the following:
I'm adding a new attribute set and I want it to be available on my stage and later the live server. Since these settings are in the database, I could just do a mysqldump and restore this dump on my stage/live systems.
But I can't do this, since the database has more data like orders, articles (with current stock availability) and a lot more stuff which I don't want to deploy from my testing system.
How are others handling this deployment "problem"?
After some testing, I chose the extension Mageploy, which is nicely to install via modman (I prefer modgit which relies on the same data for installation) and already captures a lot important backend settings.
If you need more, it's possible to extend it to more backend settings by yourself (and then contribute to the git project. Pullrequests are concidered quickly)
We have an net 4.0 winforms application that we publish with clickonce to the client pc's. The installation is about 80 MB. The application is offline available and the update occurs in the startup of the app using
ApplicationDeployment.CurrentDeployment.Update
Each time we do an update of the application everything works fine and each client gets udpated. However the application cache keeps growing in size... We noticed that more then two versions are kept in the LocalAppData folder. The size of the clickonce installation folder is more then 1GB.
ClearOnlineAppCache works only for online applications and we don't find any information to clean the LocalAppData for offline application.
Is there any way to manage previous versions of our application in the LocalAppData folder from our client pc's?
Update:
We removed our custom update code and used the update mechanism of the Clickonce framework. Now old versions are removed properly and only two versions are kept in LocalAppData. I have still no idea why all versions are kept when we update through the custom update code.
I've seen this issue before, but I clarified with the ClickOnce lead at Microsoft before answering.
It keeps two versions of the deployment plus there are extra folders for each assembly. When processing an update, ClickOnce figures out which files have changed by comparing against the assembly it has already cached, and it only downloads the ones that have changed. The deployment folders have hard links to the assemblies in the separate folders. So you might see additional files, but it's not actually the file, it's a link to the files in the assembly-only folders. Explorer will show it as a file, but it's not. So unless you're running out of disk space and are just concerned about the folder size, be aware that the information reported by Windows Explorer may not be accurate.
There is an answer to this problem here
I wrote a function to clean old ClickOnce versions in the client side.
In my machine I've freed 6Gb of space. I don't want to even know the total space used by old versions org wide...