Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-build] Successful release jobs not going to sonatype staging

I've written the following bug to document a problem getting the jakartaee-stable projects written to staging.   Posting this here since I am currently held up by this issue.   https://bugs.eclipse.org/bugs/show_bug.cgi?id=540917

On Thu, Nov 8, 2018 at 8:03 AM Jim Krueger <jckofbyron@xxxxxxxxx> wrote:
Thanks,  I've opened the following bug to track this:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=540917

On Thu, Nov 8, 2018 at 1:59 AM Maxim Nesen <maksym.nesen@xxxxxxxxxx> wrote:
Hi Jim,

I was inspecting 2 release jobs (Management-API-Release and Enterprise-Deployment-Release) and I did not find any visible reason why results of those 2 jobs differs (1 is visible in staging and another is not visible). I would file a bug to Eclipse to check if every groupId of projects being relesed from JakartaEE-Stable is allowed in staging. It might appear that something is not well configured.

Regards
Maxim  
---------- Původní e-mail ----------
Od: Jim Krueger <jckofbyron@xxxxxxxxx>
Komu: maksym.nesen@xxxxxxxxxx
Datum: 7. 11. 2018 17:37:46
Předmět: Re: Successful release jobs not going to sonatype staging
Maxim,
I'm still experiencing a curiosity/problem.   There are 4 jakartaee-stable projects (enterprise-deployment, jax-rpc-api, jaxr-api, and management-api).   I've tried creating both the enterprise-deployment and jax-rpc-api finalize jobs (your step 1 only),  but the output only shows the management-api project:
[INFO] jakartamanagementj2ee-1002 OPEN     Implicitly created (auto staging).

I've tried re-running the build and release jobs for each of these, but the results of the rc-list do not change.   Suggestions?   Thanks

On Wed, Nov 7, 2018 at 8:34 AM Jim Krueger <jckofbyron@xxxxxxxxx> wrote:
That worked!!   Thanks for the support Maxim.

On Wed, Nov 7, 2018 at 8:26 AM Jim Krueger <jckofbyron@xxxxxxxxx> wrote:
Maxim,
I realized my mistake and added the branch to the parameters.   However the  export STAGING_CONFIG=${1} is now causing me a problem since I'm not sure what to put in for this for enterprise-deployment.   I'll keep working this, but suggestions would be appreciated.   Thanks

On Wed, Nov 7, 2018 at 8:01 AM Jim Krueger <jckofbyron@xxxxxxxxx> wrote:
Hi Maxim,
I attempted to create a finalize job for the stable enterprise-deployment project containing just the first step script you indicated.  However it failed with the following messages.  Can you please take a quick look at this job?  Thanks.

Started by user James Krueger
Agent default-java-vrrkt is provisioned from template Kubernetes Pod Template
Agent specification [Kubernetes Pod Template] (): 

[EnvInject] - Loading node environment variables.
Building remotely on default-java-vrrkt in workspace /home/jenkins/workspace/Enterprise-Deployment-Finalize
[WS-CLEANUP] Deleting project workspace...
Cloning the remote Git repository
Cloning repository git@xxxxxxxxxx:eclipse-ee4j/enterprise-deployment.git
 > git init /home/jenkins/workspace/Enterprise-Deployment-Finalize # timeout=10
Fetching upstream changes from git@xxxxxxxxxx:eclipse-ee4j/enterprise-deployment.git
 > git --version # timeout=10
using GIT_SSH to set credentials GitHub Bot SSH
 > git fetch --tags --progress git@xxxxxxxxxx:eclipse-ee4j/enterprise-deployment.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url git@xxxxxxxxxx:eclipse-ee4j/enterprise-deployment.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git config remote.origin.url git@xxxxxxxxxx:eclipse-ee4j/enterprise-deployment.git # timeout=10
Fetching upstream changes from git@xxxxxxxxxx:eclipse-ee4j/enterprise-deployment.git
using GIT_SSH to set credentials GitHub Bot SSH
 > git fetch --tags --progress git@xxxxxxxxxx:eclipse-ee4j/enterprise-deployment.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/${BRANCH}^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/${BRANCH}^{commit} # timeout=10
 > git rev-parse origin/${BRANCH}^{commit} # timeout=10
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
Started calculate disk usage of build
Finished Calculation of disk usage of build in 0 seconds
Started calculate disk usage of workspace
Finished Calculation of disk usage of workspace in 0 seconds
Finished: FAILURE

On Wed, Nov 7, 2018 at 7:13 AM Jim Krueger <jckofbyron@xxxxxxxxx> wrote:
Thanks,   This looks like something that should be added to the instructions.   We saw (finalize) jobs in other projects Jenkins dashboards but did not have authority to look at their scripts.

On Wed, Nov 7, 2018 at 1:16 AM Maxim Nesen <maksym.nesen@xxxxxxxxxx> wrote:
Hello Jim,

Jobs are correct - they upload prepared artifact to staging. However after the job is done it is required to perform 2 more steps:

1. check what is uploaded using Nexus staging plugin:

Example of script:

export STAGING_CONFIG=${1}

export STAGING_PARAMS='-DnexusUrl=https://oss.sonatype.org/ -DserverId=ossrh'
export STAGING_PLUGIN='org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7'


mvn -s ${STAGING_CONFIG} ${STAGING_PARAMS} ${STAGING_PLUGIN}:rc-list

after you will receive list of open (and closed) stagings and you can identify yours by <groupId>-<number>. 

The groupId is used without dots. Like jakartajaxws-1003

and the 2nd step is to close that open staging:

2. Closing script (using the same maven staging plugin):

export STAGING_DESC=${1}
export STAGING_REPO_ID=${2}
export STAGING_CONFIG=${3}

export STAGING_PARAMS='-DnexusUrl=https://oss.sonatype.org/ -DserverId=ossrh'
export STAGING_PLUGIN='org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7'


mvn -s ${STAGING_CONFIG} ${STAGING_PARAMS} ${STAGING_PLUGIN}:rc-close -DstagingRepositoryId="${STAGING_REPO_ID}" -DstagingDescription="${STAGING_DESC}"

STAGING_REPO_ID is required identifier from previous step, 
STAGING_DESC is description of the staging taken from the dependencies image: https://wiki.eclipse.org/images/2/24/EE4J_projects_dependencies.png

STAGING_CONFIG is config file for maven (like settings.xml)

However if you do not find required staging in nexus using the 1st step you have to re-run release job (with OVERWRITE parameter checked) and perform those 2 steps after release job is done. Those 2 steps can be put in jenkins job and triggered after the release build is successful.  

Shall you have any questions please contact me :)

Regards,
Maxi

---------- Původní e-mail ----------
Od: Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>
Komu: Jim Krueger <jckofbyron@xxxxxxxxx>
Datum: 6. 11. 2018 23:25:15
Předmět: Re: Successful release jobs not going to sonatype staging
Jim, something is definitely not right. Adding Maxim. Maxim, can you please take a look on JAX-RPC API and JACC jobs and tell us what’s wrong with them. 

— Dmitry

On 6 Nov 2018, at 23:14, Jim Krueger <jckofbyron@xxxxxxxxx> wrote:

Hi Dmitry,
The Jenkins release jobs I've set up for the Jakartaee stable projects using the provided example are running successfully,  however it does not appear that the sonatype staging repository is being updated with these projects. 

This may or may not be related,  but when I look in the Console output for these jobs I see lines like this:
However, if I click any of these links I see this:

This XML file does not appear to have any style information associated with it. The document tree is shown below.
     <nexus-error><errors><error><id>*</id><msg>Staging of Repository within profile ID=‘7edbe315063867’ is not yet started!</msg></error></errors></nexus-error>

Are there some instructions I am missing?   We are seeing the same results for the JCA project as well.

Thanks


Back to the top