Thanh,

Thank You for taking time to move this topic forward, in parallel to everything else going on! 

The (for now manual) p2 site looks good.

Not sure if you were expecting me and / or David to help with wrapping it up? My bash skills are too limited to write some smart regexp or something re the TODO to extract that version.. but, personally, I would for now keep this very simple. And so re. last paragraph, again me personally I would not spend man cycles on multi branch, at this stage, for building maintenance branches of old yangide versions. David, chime in if you strongly disagree. Because yangide bundles yangcore, I think over time this may later, be a requirement, I'm not even sure, if folks need to use the Eclipse IDE provisioning to maintain older branches and use yangide to validate yang and code generate in IDE with the yang core matching that maintenance branch version. But worrying about that seems a little premature to me at this stage.

Regards, and thanks again,
Michael

Thanh,

Thank You for taking time to move this topic forward, in parallel to everything else going on! 

The (for now manual) p2 site looks good.

Not sure if you were expecting me and / or David to help with wrapping it up? My bash skills are too limited to write some smart regexp or something re the TODO to extract that version.. but, personally, I would for now keep this very simple. And so re. last paragraph, again me personally I would not spend man cycles on multi branch, at this stage, for building maintenance branches of old yangide versions. David, chime in if you strongly disagree. Because yangide bundles yangcore, I think over time this may later, be a requirement, I'm not even sure, if folks need to use the Eclipse IDE provisioning to maintain older branches and use yangide to validate yang and code generate in IDE with the yang core matching that maintenance branch version. But worrying about that seems a little premature to me at this stage.

Regards, and thanks again,
Michael

On 20 May 2016 03:30, "Thanh Ha" <thanh.ha@...> wrote:

Hi Michael,

(also adding David so he's in the loop)

(and adding dev list back as I really dislike having private conversations in an open source project, please use a mailing list when possible in the future.)

I've submitted a DRAFT patch [0] that modifies the jobs to release to yangide/release and yangide/snapshot URLs in the p2repo nexus site. This patch still needs work but I ran some manual testing and pushed a few artifacts to yangide snapshot [1]. I hope this unblocks your efforts even if we have to run the job manually until we have the full job working in an automated fashion.

I think we need to create a custom yangide-merge job so that we can tell it to kick off a build of the p2 publisher job at the end of the build before we can merge patch [0]. Alternatively we have the p2 publisher job watch yangide-merge* jobs and only publish the latest snapshot if we don't care about maintaining maintenance branches of old yangide versions.

Regards,

Thanh

[0] https://git.opendaylight.org/gerrit/39132/

[1] https://nexus.opendaylight.org/content/sites/p2repos/org.opendaylight.yangide/snapshot/

On 18 May 2016 at 10:35, Thanh Ha <thanh.ha@...> wrote:

Hi Michael,

Unfortunately I'm gonna have to put a stop on your Jenkins idea. Our Jenkins instance is already struggling from being overloaded and stressed from the scale of our build system and we're working on finding ways to move things off of Jenkins as it has some major scale issues so we're trying to stop people from needing to navigate to Jenkins at all.

Storing artifacts, especially p2 artifacts in Jenkins would cause serious load issues on our Jenkins server that we do not want at this point.

The p2 zip file that's stored in Nexus snapshots can be downloaded and unzipped your local system and Eclipse supports using a local directory as a path for a p2 repo. So your temporary workaround can be a step for your users to download the p2 zip file, unzip it somewhere in their file system and add the path as the p2 URL in Eclipse as their update site.

This is all that Nexus does when we push the p2.zip file to Nexus too. As I mentioned, yes it's a pain right now however it works and is only a slight inconvenience to your users in my opinion. Does this work for you?

Regards,

Thanh

On 18 May 2016 at 07:21, Michael Vorburger <vorburger@...> wrote:

Hi! [please shout if you would rather we have this discussion in public on list?],

On Tue, May 17, 2016 at 3:22 PM, Thanh Ha <thanh.ha@...> wrote:

Thanh, so when will I get my p2 SNAPSHOT site for yangide? I'm sure it's on your plate.. like many other things? ;)

With that said while we wait one thing we can do is design the JJB template.

Not sure if I could do something here in the mean time? Until it's available, I think this is premature. (BTW: I haven't had time yet for our point re. UI tests, but will hopefully get to that soon.)

 

My focus this week is on migrating our Jenkins Sandbox system to the private cloud as this is our most important action item right now and testing all our Vagrant images so I'm not sure I'll find any time this week for that.

I see.

  

Are you blocked on work because of this?

 

Again I don't mean to be a pain or stress, so this is just to explain where I am sitting: I actually am kind of blocked - I'd like to get yangide auto. bundled into https://github.com/vorburger/opendaylight-eclipse-setup ASAP, and for that I need to have an HTTP p2 site of it somewhere. I could perhaps workaround through a built ZIP onto a personal Dropbox or something, but I would rather have a real CI, so that we can keep working on yangide and get latest changes automatically installed by Oomph. Or I could set up a job on another Jenkins somewhere, perhaps I could find a public one at Red Hat, but setting that up seems... a little silly, just for something so little. (We ARE actually building yangide, just struggling to serve its p2 repo.)

my understanding is that you can get the latest yangide via Maven snapshots although it's inconvenient.

Sorry here I don't follow - I cannot use this as a p2 site, or can I ?  I don't see how.

 

I know you're excited for getting this going so maybe I can find some time over the long weekend coming up this weekend.

No no, you should not have to work over a weekend (I try to remind myself that I work to live, not only live to work..).

Here is another idea: While I do fully understand that you guys, you and Andrew, consider jenkins to be the build machine only and want nexus to be the repository, couldn't we, in the interest of unblocking https://bugs.opendaylight.org/show_bug.cgi?id=5869 and pragmatic moving forward, agree that you would merge a change I could probably make fairly easily to the yangide JJB template so that it would do a Post-build Action: Archive the artifacts: product/update-site/target/repository/**/* (with Advanced. Archive artifacts only if build is successful) .. that would then make a yangide p2 site on http://.../job/yangide/lastSuccessfulBuild/artifact/product/update-site/target/repository/ - and the short term problem is solved! I've actually just taken a moment to try this out locally; I just downloaded a Jenkins myself to try - this approach works great! I cannot imagine this being a problem e.g. in terms of traffic on *.opendaylight.com - with the amount of bits I'm assuming you have to deliver from nexus.opendaylight.org, I don't see how a plugin JAR served from jenkins.opendaylight.org could be a real issue, do you? Yes jenkins is not as optimized as an HTTP content server as Nexus, sure - but we're talking about some people occasionally downloading this plugin  via https://github.com/vorburger/opendaylight-eclipse-setup - I'm pretty sure this should be OK, for now. Once you have the deployment sorted out on nexus, I'll just change the URL in that setup model, and we'll remove the Post-build Action: Archive the artifacts again then.

What do you think? If I work on changing the yangide JJB with a Post-build Action: Archive the artifacts, and test it in sandbox, will you merge it, or have to push back because we seriously absolutely cannot serve and content other than HTML from jenkins?

Last but not least, just FYI: I may soon have a similar requirement for another ODL Eclipse plugin - depending on the outcome of how I can solve https://sourceforge.net/p/eclipse-cs/feature-requests/159/ ..

Thanks!!!

M.

--

Michael Vorburger <vorburger@...> | IRC: vorburger @freenode | G/Hangout: michael.vorburger | Skype: mike_vorburger | ~ = http://vorburger.ch