March 2017 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-23768) Publish tagged version of jboss tools parent pom to public repository

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23768?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-23768 at 3/1/17 11:14 AM: ------------------------------------------------------------- Yes, you're right. Missed the last step. This means that the script I send Jeff to do branching has to happen BEFORE the branch update & parent pom release; THEN when that's done we can send out the SECOND script to update root poms. Sucks to have to have a manual human process in the middle of two mostly-automated ones. Will have to think about how we can make the parent pom commits generated & pushed to github automatically... * branch jbosstools-build (4.4.4.x and later again for 4.5.0.x); send email to Jeff w/ instructions for batch creation of jbosstools-* projects' branches * update parent pom to use correct "stable branch" settings [1] & update version (remove -SNAPSHOT) [2] *could this be done by Jenkins job in future?* * trigger build which will now auto-release it to Nexus [3] *could this be triggered automatically via upstream job in future?* * send email to Jeff w/ instructions for batch changes to jbosstools-* projects' root poms (point to non-SNAPSHOT version of parent pom) Maybe a build pipeline would work for this, with a blocking step #2 until we can replace it with a script. [~jeffmaury] would you be OK if the devstudio-release machine user [4] had push rights to the parent pom in jbosstools-build [5]? [4] https://github.com/devstudio-release [5] https://github.com/jbosstools/jbosstools-build was (Author: nickboldt): Yes, you're right. Missed the last step. This means that the script I send Jeff to do branching has to happen BEFORE the branch update & parent pom release; THEN when that's done we can send out the SECOND script to update root poms. Sucks to have to have a manual human process in the middle of two mostly-automated ones. Will have to think about how we can make the parent pom commits generated & pushed to github automatically... * branch jbosstools-build (4.4.4.x and later again for 4.5.0.x); send email to Jeff w/ instructions for batch creation of jbosstools-* projects' branches * update parent pom to use correct "stable branch" settings [1] & update version (remove -SNAPSHOT) [2] *could this be done by Jenkins job in future?* * trigger build which will now auto-release it to Nexus [3] *could this be triggered automatically via upstream job in future?* * send email to Jeff w/ instructions for batch changes to jbosstools-* projects' root poms (point to non-SNAPSHOT version of parent pom) Maybe a build pipeline would work for this, with a blocking step #2 until we can replace it with a script. [~jeffmaury] would you be OK if the devstudio-release machine user had push rights to the parent pom in jbosstools-build? > Publish tagged version of jboss tools parent pom to public repository > --------------------------------------------------------------------- > > Key: JBIDE-23768 > URL: https://issues.jboss.org/browse/JBIDE-23768 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.4.2.Final, 4.4.3.AM1 > Reporter: Aurélien Pupier > Assignee: Nick Boldt > Labels: releasework > Fix For: 4.4.3.Final > > > it will allow Fuse Tooling (and other dependent projects) to have tagged version of their parent pom for tagged release. > i'm talking about org.jboss.tools:parent -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23768) Publish tagged version of jboss tools parent pom to public repository

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23768?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23768: ------------------------------------ Yes, you're right. Missed the last step. This means that the script I send Jeff to do branching has to happen BEFORE the branch update & parent pom release; THEN when that's done we can send out the SECOND script to update root poms. Sucks to have to have a manual human process in the middle of two mostly-automated ones. Will have to think about how we can make the parent pom commits generated & pushed to github automatically... * branch jbosstools-build (4.4.4.x and later again for 4.5.0.x); send email to Jeff w/ instructions for batch creation of jbosstools-* projects' branches * update parent pom to use correct "stable branch" settings [1] & update version (remove -SNAPSHOT) [2] *could this be done by Jenkins job in future?* * trigger build which will now auto-release it to Nexus [3] *could this be triggered automatically via upstream job in future?* * send email to Jeff w/ instructions for batch changes to jbosstools-* projects' root poms (point to non-SNAPSHOT version of parent pom) Maybe a build pipeline would work for this, with a blocking step #2 until we can replace it with a script. [~jeffmaury] would you be OK if the devstudio-release machine user had push rights to the parent pom in jbosstools-build? > Publish tagged version of jboss tools parent pom to public repository > --------------------------------------------------------------------- > > Key: JBIDE-23768 > URL: https://issues.jboss.org/browse/JBIDE-23768 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.4.2.Final, 4.4.3.AM1 > Reporter: Aurélien Pupier > Assignee: Nick Boldt > Labels: releasework > Fix For: 4.4.3.Final > > > it will allow Fuse Tooling (and other dependent projects) to have tagged version of their parent pom for tagged release. > i'm talking about org.jboss.tools:parent -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23768) Publish tagged version of jboss tools parent pom to public repository

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23768?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-23768: --------------------------------------- I think you missed the final step ;) * update the branch (4.4.4.x and later again for 4.5.0.x) in all repos to point to the non-snapshot version of parent pom. And all of this before the repos are tagged and the bits are released. My main concern here is build reproducibility - not so much whether or not the released bits have snapshots in them or not. > Publish tagged version of jboss tools parent pom to public repository > --------------------------------------------------------------------- > > Key: JBIDE-23768 > URL: https://issues.jboss.org/browse/JBIDE-23768 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.4.2.Final, 4.4.3.AM1 > Reporter: Aurélien Pupier > Assignee: Nick Boldt > Labels: releasework > Fix For: 4.4.3.Final > > > it will allow Fuse Tooling (and other dependent projects) to have tagged version of their parent pom for tagged release. > i'm talking about org.jboss.tools:parent -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23768) Publish tagged version of jboss tools parent pom to public repository

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23768?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23768: ------------------------------------ Yes, ideally we'd release the parent pom BEFORE everything that depends on it goes to Final/GA... but in this case there were a few changes to the parent pom I needed to do AFTER the GA builds were done. https://github.com/jbosstools/jbosstools-build/commits/jbosstools-4.4.3.x... Since none of these affect downstream builds (they're just in support of being able to release the pom to Nexus) I didn't feel the need to rebuild everything using the .Final version after releasing it. So in future we can do this: * branch (4.4.4.x and later again for 4.5.0.x) * update parent pom to use correct "stable branch" settings [1] & update version (remove -SNAPSHOT) [2] * trigger build which will now auto-release it to Nexus [3] [1] https://github.com/jbosstools/jbosstools-build/commit/34d346227e412e354e3... [2] https://github.com/jbosstools/jbosstools-build/commit/25e2ae4e00ccbbd2236... [3] https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo... > Publish tagged version of jboss tools parent pom to public repository > --------------------------------------------------------------------- > > Key: JBIDE-23768 > URL: https://issues.jboss.org/browse/JBIDE-23768 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.4.2.Final, 4.4.3.AM1 > Reporter: Aurélien Pupier > Assignee: Nick Boldt > Labels: releasework > Fix For: 4.4.3.Final > > > it will allow Fuse Tooling (and other dependent projects) to have tagged version of their parent pom for tagged release. > i'm talking about org.jboss.tools:parent -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23768) Publish tagged version of jboss tools parent pom to public repository

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23768?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-23768: --------------------------------------- The downside of this is that tags of github repos were created before this was done and now they contain a reference to the snapshot version of parent pom and the build is broken in the tag. For example see here: https://github.com/jbosstools/jbosstools-server/blob/jbosstools-4.4.3.Fin... I suggested a fix here: https://github.com/jbosstools/jbosstools-server/pull/469 Next time the parent pom should be released first, then the change pushed to the depending repos and finally make the release tag. Even here, we could fix this in all repos in jbosstools-4.4.3.x branch and then update the jbosstools-4.4.3.Final tag. > Publish tagged version of jboss tools parent pom to public repository > --------------------------------------------------------------------- > > Key: JBIDE-23768 > URL: https://issues.jboss.org/browse/JBIDE-23768 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.4.2.Final, 4.4.3.AM1 > Reporter: Aurélien Pupier > Assignee: Nick Boldt > Labels: releasework > Fix For: 4.4.3.Final > > > it will allow Fuse Tooling (and other dependent projects) to have tagged version of their parent pom for tagged release. > i'm talking about org.jboss.tools:parent -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBDS-4286) fix migrated jobs that rely on /qa/services/http/binaries/ or /home/hudson/static_build_env/

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-4286?page=com.atlassian.jira.plugin.... ] Nick Boldt reassigned JBDS-4286: -------------------------------- Assignee: Nick Boldt > fix migrated jobs that rely on /qa/services/http/binaries/ or /home/hudson/static_build_env/ > -------------------------------------------------------------------------------------------- > > Key: JBDS-4286 > URL: https://issues.jboss.org/browse/JBDS-4286 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Sub-task > Components: build > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 10.4.0.AM1 > > > Some jobs that would benefit from sshfs mounted drives or using different paths (they all rely on access to /qa/services/http/binaries/ or /home/hudson/static_build_env/ ) > https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... > https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... > https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... > https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23889) jbosstools-composite-install_master sends lots of nag emails when something goes awry (as it should)

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23889?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-23889: ---------------------------------------- 30 minutes is OK, the issue was that for a couple of days, this setting was simply ignored so the build was running every 30 seconds. > jbosstools-composite-install_master sends lots of nag emails when something goes awry (as it should) > ---------------------------------------------------------------------------------------------------- > > Key: JBIDE-23889 > URL: https://issues.jboss.org/browse/JBIDE-23889 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.3.AM2 > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.4.4.AM1 > > Attachments: composite.png > > > jbosstools-composite-install_master re-runs itself on failure. However, it seems like the SLEEP_TIME parameter is now ignored, resulting on constant re-run of the job and a lot of spam (multiple mails per minutes). Additionally to spam, this adds a relatively big load on Jenkins and slaves queue. > I've removed the re-run on failure block of the downstream job trigger as a temporary workaround. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23889) jbosstools-composite-install_master sends lots of nag emails when something goes awry (as it should)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23889?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23889: ------------------------------------ I changed the SLEEPTIME from 30 mins to 180 mins yesterday: https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/DevStudio/view/... Once everyone's builds are actually compiling again (lots of baseline check failures because several projects forgot to upversion plugins/features) I can put it back to 30 min intervals. > jbosstools-composite-install_master sends lots of nag emails when something goes awry (as it should) > ---------------------------------------------------------------------------------------------------- > > Key: JBIDE-23889 > URL: https://issues.jboss.org/browse/JBIDE-23889 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.3.AM2 > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.4.4.AM1 > > Attachments: composite.png > > > jbosstools-composite-install_master re-runs itself on failure. However, it seems like the SLEEP_TIME parameter is now ignored, resulting on constant re-run of the job and a lot of spam (multiple mails per minutes). Additionally to spam, this adds a relatively big load on Jenkins and slaves queue. > I've removed the re-run on failure block of the downstream job trigger as a temporary workaround. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24010) build: bump plugin version to comply with baseline check

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24010?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-24010: ------------------------------------ Added a few more plugins/features to the pile of things incremented to 3.3.3 and now it compiles: https://github.com/jbosstools/jbosstools-openshift/pull/1433 > build: bump plugin version to comply with baseline check > -------------------------------------------------------- > > Key: JBIDE-24010 > URL: https://issues.jboss.org/browse/JBIDE-24010 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.5.0.AM1 > Reporter: Nick Boldt > Assignee: Andre Dietisheim > Priority: Blocker > Fix For: 4.4.4.AM1, 4.5.0.AM1 > > > {code} > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:1.0.0:compare-version-with-baselines > (default) on project org.jboss.tools.openshift.client: Version have moved backwards for > (org.jboss.tools.openshift.client/3.3.2.AM1-v20170224-1533-B1868). > Baseline has 3.3.2.Final-v20170217-1414-B33) with delta: 0.0.0 > {code} -- https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/DevStudio/view/... > Solution: upversion your client plugin or make it not use the BUILD_ALIAS in its version (so it's only got a timestamp). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24010) build: bump plugin version to comply with baseline check

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24010?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-24010: ------------------------------------ When I build your PR I get 2 additional plugins and one feature that need to be incremented: {code} [ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:0.26.0:compare-version-with-baselines (default) on project org.jboss.tools.openshift.common.ui: Duplicate version but different content found for (org.jboss.tools.openshift.common.ui/3.3.2.v20170202-1544). Also exists in baseline, but its content is different. -> [Help 1] [ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:0.26.0:compare-version-with-baselines (default) on project org.jboss.tools.openshift.core: Version have moved backwards for (org.jboss.tools.openshift.core/3.3.2.v20170215-1207). Baseline has 3.3.2.v20170217-1329) with delta: 0.0.0 -> [Help 1] [ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:0.26.0:compare-version-with-baselines (default) on project org.jboss.tools.openshift.egit.integration.feature: Duplicate version but different content found for (org.jboss.tools.openshift.egit.integration.feature.source.feature.jar/3.3.2.v20161213-1011). Also exists in baseline, but its content is different. -> [Help 1] {code} > build: bump plugin version to comply with baseline check > -------------------------------------------------------- > > Key: JBIDE-24010 > URL: https://issues.jboss.org/browse/JBIDE-24010 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.5.0.AM1 > Reporter: Nick Boldt > Assignee: Andre Dietisheim > Priority: Blocker > Fix For: 4.4.4.AM1, 4.5.0.AM1 > > > {code} > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:1.0.0:compare-version-with-baselines > (default) on project org.jboss.tools.openshift.client: Version have moved backwards for > (org.jboss.tools.openshift.client/3.3.2.AM1-v20170224-1533-B1868). > Baseline has 3.3.2.Final-v20170217-1414-B33) with delta: 0.0.0 > {code} -- https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/DevStudio/view/... > Solution: upversion your client plugin or make it not use the BUILD_ALIAS in its version (so it's only got a timestamp). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues March 2017