Incident #5634
closed
Wrong IC client library versions on Nexus
Added by Gianpaolo Coro over 8 years ago.
Updated over 8 years ago.
Category:
High-Throughput-Computing
Infrastructure:
Production
Description
In the staging Maven repository, ic-client versions are present, which have not been released (ic-client-1.0.1-None, ic-client.1.0.2.jar, ic-client.2.0.0-SNAPSHOT ).
This corrupted several DataMiner service installations.
Could you please investigate the reason and if there are other libraries like these?
- Related to Task #5590: DataMiner as Generic Worker added
- Status changed from New to In Progress
So, I found other few components with this "exotic" versioning (i.e. common-scope, registry-publisher), but only the ic-client one had a version greater that the one currently in release (this is probably the reason for which we had the issue).
Concerning the reasons, from the metadata we cannot know who uploaded them. They probably comes from a couple of builds (between March and May) launched with incorrect options. It could have been a build of ic-client.HEAD (that was at version 2.0.0 in HEAD for a certain period of time) launched using a release project configuration of gCube. Unfortunately we do not have a simple way to track these events when they happen.
However, if I understood correctly the problem, the dataminer artifact included the wrong version of ic-client library. This should never happen in ETICS (access to remote repositories is disabled), so I'm assuming you did the build locally. The dataminer artifacts on gcube-staging are not affected by this problem, is this correct?
yes it comes out when the dependencies of DataMiner are downloaded during the creation of the Web app.
For the future, I double checked the integration scripts and verified that wrong versions are not created. In order to be sure to remove all bad artifacts currently in the gcube-staging, we could completely clean the repository. @roberto.cirillo@isti.cnr.it do you see any major drawback in doing this?
As general rule, gcube-staging should not be used for local builds. It is meant to be used only by the ETICS integration builds as storage for artifacts that must be tested.
Gabriele Giammatteo wrote:
For the future, I double checked the integration scripts and verified that wrong versions are not created. In order to be sure to remove all bad artifacts currently in the gcube-staging, we could completely clean the repository. @roberto.cirillo@isti.cnr.it do you see any major drawback in doing this?
In my opinion the cleaning of all artifacts from staging could be dangerous.
In order to clean the staging repository, Is it possible to temporary transfer all the artifacts from staging to another temporary repository?
In this way we are able to restore all the artifacts if something goes wrong.
- Status changed from In Progress to Feedback
it seems to be possible but only modifying the underlying filesystem [1] in the our Nexus version. However, now that the release is closed, all the artifacts in gcube-staging are already in gcube-releases, I would not be too worried about loosing artifacts.
In any case, a more prudent option can be to keep the content until next release, in case we need any of the artifacts before next release starts.
In the meantime, @gianpaolo.coro@isti.cnr.it, can we consider the incident resolved?
[1] http://blog.sonatype.com/2010/04/nexus-tip-moving-artifacts-between-nexus-repositories/
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
