Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-build] how to release staged artifacts?

Romain Grécourt wrote on 10/16/18 04:08 PM:
On Tue, Oct 16, 2018 at 3:26 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
Romain Grécourt wrote on 10/12/18 01:06 PM:
There's way too many options and choices there.  I'm really hoping someone else who really understands this stuff has figured out exactly how to do this for our Eclipse projects.


            <plugin>
                <groupId>org.sonatype.plugins</groupId>
                <artifactId>nexus-staging-maven-plugin</artifactId>
                <extensions>true</extensions>
                <configuration>
                    <serverId>ossrh</serverId>
                    <nexusUrl>https://oss.sonatype.org/</nexusUrl>
                </configuration>
            </plugin>

You can configure the plugin to automatically release the staging repository (autoReleaseAfterClose=true).
I.e, this makes the nexus workflow transparent.
I assume we don't want to do this because we need to wait for Release Review approval before releasing the staged artifacts.

You could also implement the workflow manually. (skipStagingRepositoryClose=true)
I assume this is what we want.  Is this not the default?

The way I understand it the default configuration of the plugin will leave with a closed staging repository.
Is there some reason I shouldn't want it to be closed automatically?  As long as it's not released, that seems fine.

What can I do with it when it's not closed, other than close it?



It would look like something like this:

# Create the nexus staging repository
STAGING_DESC="Project ACME v${FULL_VERSION}"
mvn nexus-staging:rc-open \
  -DstagingProfileId=6026dab46eed94 \
  -DstagingDescription="${STAGING_DESC}"
Where does the stagingProfileId come from?

Of course I had to create a Jenkins job to use rc-list-profiles.  I got this:

[INFO]  * Connected to Nexus at https://oss.sonatype.org:443/, is version 2.14.10-01 and edition "Professional"
[INFO] Getting list of available staging profiles...
[INFO] 
[INFO] ID              Mode   Name                          
[INFO] 7edbe315063867  BOTH   Central Bundles               
[INFO] 70fc011e3d589e  BOTH   jakarta.activation            

Does that mean I can hard code "70fc011e3d589e" in my script and never need to change it (as long as my groupId doesn't change)?

 

How often do I need to create the staging repository?  Once ever?  Every time I want to stage something new?

Every time you deploy. Without using this plugin, nexus creates one on the fly.
This is why on maven.java.net you had to go to nexus and then close/release.


STAGING_REPO_ID=$(mvn nexus-staging:rc-list | \
  egrep "^\[INFO\] orgacme\-[0-9]+[ ]+OPEN[ ]+${STAGING_DESC}" | \
  awk '{print $2}' | head -1)
What is "orgacme" above?
This is the profile name. I got that value with rc-list-profiles (see above).
In my case it's "jakartaactivation" (no dots).  I suppose it's derived from the groupId?


# Perform deployment
mvn deploy -DstagingRepositoryId=${STAGING_REPO_ID}

# Close and release the nexus staging repository
mvn nexus-staging:rc-close nexus-staging:rc-release \
  -DstagingRepositoryId=${STAGING_REPO_ID} \
  -DstagingDescription="${STAGING_DESC}"
Can I put the above in a Jenkins job separate from the "mvn deploy" command?  I'm not clear on what the lifetime is of the value in STAGING_REPO_ID.  If I compute it once in the "mvn deploy" job and again in the "rc-release" job, will it have the same value? 

Yes, you could automate the workflow with a difference job. 
Note that here I'm expecting only one staging repository so I grab the first one.

We could think of a convention in the staging repository description and match that with a parameter on the job.
E.g This job takes a version as parameter and the script uses that to match the right repository and complete the workflow.
Can there be multiple staging repos for the same artifact?

If I forget to release or drop one, that would be a problem.  I guess I should iterate over all the repos and close drop them all before creating a new one.

Ok, I'm getting pretty close to getting this working (I think).  Now I just need to get permission to deploy org.eclipse.activation and org.eclipse.mail groupIds (since we seem to have decided to stop using com.sun.*).


Back to the top