Maven deploy: dwingt de deploy zelfs als artefact al bestaat

Ik ben een project aan het bouwen dat bestaat uit verschillende (soms niet-gerelateerde) modules en enkele meer niet-standaard Java-modules (gebouwd met ANT).

Elke maven-module wordt na voltooiing geïmplementeerd in de releasebibliotheek.

Als de build in het midden faalt, kan het zijn dat sommige modules al zijn geïmplementeerd, dus als ik probeer opnieuw te bouwen, mislukt de nieuwe poging om te implementeren omdat de artefacten al zijn geïmplementeerd.

Is het mogelijk om een ​​deploy te forceren of, in plaats daarvan, het gebruikte artefact te verwijderen voordat ik het opnieuw implementeer?

 15
toegevoegd
Bekeken: 1
de bron
ja ru pt de ar
Andrew - AFAIK, als je een bestaand artefact probeert opnieuw in te zetten, zul je falen.
toegevoegd de auteur Eldad AK, de bron
@khmarbaise - het is niet dat de implementatie mislukt. Het is een compleet bouwproces dat mislukt. Sommige modules zijn al geïmplementeerd ... en sommige niet. Ik wil de geïmplementeerde versies terugdraaien/annuleren, zodat ik opnieuw kan bouwen (waardoor de mislukte modules opnieuw worden geïmplementeerd).
toegevoegd de auteur Eldad AK, de bron
Ja. Fouten in ander deel van de build. De "Build" bestaat uit vele modules (sommige maven, andere niet). Een "geslaagd" -ontwerp zal er een zijn waarbij alle modules met succes zijn gebouwd.
toegevoegd de auteur Eldad AK, de bron
probeer mvn release: rollback
toegevoegd de auteur om39a, de bron
@ om39a Een mvn-release: rollback verwijdert geen artefacten uit de repository.
toegevoegd de auteur khmarbaise, de bron
De gebruikelijke opstelling van repository-managers is om redenen van herverdeling geen artefacten toe te staan. De vraag is: waarom mislukt een implementatie? Als het niet lukt, is er iets mis en werkt uw configuratie niet.
toegevoegd de auteur khmarbaise, de bron
En wat is de reden voor het falen? Foutmeldingen ?
toegevoegd de auteur khmarbaise, de bron
Waarom mislukt de implementatie? Als u artefact met dezelfde versie implementeert, overschrijft het de bestaande.
toegevoegd de auteur Andrew Logvinov, de bron

3 antwoord

Het lijkt erop dat de middleware-beheerders je remote repo-instantie (Nexus of Artifactory of wat dan ook) hebben geconfigureerd om geen artefact-herdistributie toe te staan, en zoals @khmarbaise zegt dat daar goede redenen voor zijn. Nexus kan worden geconfigureerd om verwijdering van artefacten door gebruikers in een bepaalde rol of met verwijderbevoegdheden voor artefacten mogelijk te maken. Als uw beheerders het op die manier hebben ingesteld, kunt u misschien het verwijderingsrecht aanvragen en de aanstootgevende artefacten verwijderen. Of misschien zal de Nexus-beheerder ermee instemmen het voor u te doen.

Als geen van beide mogelijk is, zijn hier een aantal dingen om te proberen die dit mogelijk in de toekomst kunnen voorkomen:

  1. If you are using the release plugin, do a dry run (-DdryRun=true on the release:prepare command line) first. Maven should report any errors without committing to SCM.
  2. Try running mvn install on your group of projects first. This will install the artifacts to your local repo, not the remote. If there's a problem you can whack the artifacts out of your local repo and start from scratch, repeating until you get a complete build.
  3. If you are running a multi-module build, there are command line options that allow resuming a Maven build from a particular project forward.
  4. Define -Dmaven.deploy.skip=true on the Maven command line. This is similar to suggestion #2, except Maven will actually load & configure the deploy plugin, it just won't do the actual deploy to the remote repo. Once everything works, remove the skip property.
11
toegevoegd
de bron
Alle goede suggesties. Ik denk dat ik voor optie 4 of iets dergelijks ga ... Thx!
toegevoegd de auteur Eldad AK, de bron
Ik heb een soortgelijk probleem, alles ging goed totdat ik een 502 kreeg (proxyfout). Ik neem aan dat mijn uni-server dacht dat mijn verbinding een bedreiging is. Nu krijg ik 400 (Bad Request) omdat de artefacten al op de nexus-server staan. Is er een manier om een ​​release te hervatten: uitvoeren? Ik kan de artefacten verwijderen, maar dit is veel werk in het regelpaneel van de Nexus. Het lijkt erop dat ik elke versie-submap van het project met meerdere modules met de hand moet verwijderen. Ik zal proberen de volgende keer vanuit het uni-netwerk te uploaden!
toegevoegd de auteur DarthB, de bron

Ik weet dat het misschien laat is, maar in Nexus is er een optie waarbij het opnieuw inzetten van artefacten mogelijk is.

enter image description here

Selecteer gewoon de repository's aan de linkerkant, kies de repository waarvan u het beleid wilt wijzigen en stel het vervolgens in op Opnieuw toestaan ​​toelaten.

7
toegevoegd
de bron
Dit is een goede optie, maar ik ben alleen geïnteresseerd in zo'n mogelijkheid van mijn build en niemand mag een vrijgegeven artefact opnieuw inzetten. Kan ik dit tijdens de build-tijd inschakelen en uitschakelen wanneer de build is voltooid?
toegevoegd de auteur Eldad AK, de bron
denk niet dat het mogelijk is, want wie beslist of het artefact kan worden heringedeeld, is de server, niet de cliënt
toegevoegd de auteur leozin, de bron

De mogelijke opties zijn verhoogd;)

Gebruik de parameter deployAtEnd (Meer informatie: hier ). Met deze parameter worden de artefacten alleen gebruikt als alle artefacten met succes zijn gemaakt.

2
toegevoegd
de bron