The problem arose from the fact that one of the projectâs URL stayed at RC level which was removed at end of release. So we did not had access to the URL. In this case the build was failing. Once that team updated the URL the problem got resolved.
So these are my conclusions:
- We build with the content available in simrel repo. At RC4 it will be last RC URLs. These will contain final content(if there is a bug discovered we will have RC4a for that component)
- The content for final release and last RC would be same. So from build point of view there would be no change in the build content if we build with release URLs or last RC URLs.
- It is projectâs responsibility to update the URLs at the time release with release URLs. If not there is a fair chance that build may fail(as some of the URLs may not be available) at the next checkpoint
- There are two ways we can fix
- Ask the project team to update. (Preferred)
- Disable the project (use it as last resort)
Please correct me if I am wrong
From: David Williams [mailto:david_williams@xxxxxxx]
Sent: Friday, January 20, 2017 12:37 AM
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Subject: Re: [cross-project-issues-dev] Fwd: Simrel repo contributions
I will answer to "cross-project" list, since may be of general interest.
And before answering the question, I will remind everyone the purpose of the "checkpoint build" was primarily to allow any new projects, or projects with new features, to "get into" the build, on a relatively stable base. Unlike "RC builds" not all projects would be expected to update their contributions for mere bug fixes. I also noticed that this is stated in the Neon Plan, but not the Oxygen plan so ... someone ... should update the Oxygen plan as well (assuming the Planning Council still wants to provide that checkpoint, for Oxygen update releases).
I am assuming that the original issue or question revolved around someone's URL in the aggrcon file was not literally the "final release" one, in the sense that repositories are normally moved or copied to their final location during quiet week, and then the project must remember to also update their URLs in the aggrcon file.
If that is the issue, then I'll make the following comments:
a. What you say is true, project decides "the release" URL. BUT the "right content" is a little stronger than you say. It should be exactly the same. Not simply "fit in".
b. We (or, I) never hounded projects much to update their URLs to their final ones, because every year a few would not and unless everyone does it, it really does not make the build "reproducible" so I thought it not worth the hounding.
c. I did, however, set the 'validate' job (on both branches) to not only run upon git repo changes, but also to run once every Monday morning, to help spot "broken URLs". [I did not write much about these triggering events, so just now added it to the Simrel release engineering wiki.]
If that is not the issue, then I will need more specific questions, or symptoms. It appears all the URL stuff was fixed 5 days ago, so if it is still an issue, then I suspect something else is wrong.
On 01/19/2017 12:40 PM, Frederic Gurr wrote:
Can you help me with Sravan's questions?
I assume that every project is responsible to put in the right URLs for
a release. SimRel in general does not care if something is a "release"
URL, as long as the right content (whatever a project considers to be
right and what does not cause dependency issues) is available, right?
-------- Forwarded Message --------
Subject: Simrel repo contributions
Date: ÂÂ Mon, 16 Jan 2017 07:51:06 +0000
From: ÂÂ Sravan K Lakkimsetti <sravankumarl@xxxxxxxxxx>
To: ÂÂÂÂ frederic.gurr@xxxxxxxxxxx
CC: ÂÂÂÂ Daniel Megert <daniel_megert@xxxxxxxxxx>
I was trying to update simrel with latest 4.6.3 M-Build for 4.6.3 check
point. I noticed an issue with Sirius project. This raised following
questions in my mind relating to 4.6.2
1. Did we build 4.6.2 with right repos?
2. When do we do build with release urls?
3. If we did build with wrong repo urls, how to rectify that?
4. How can we catch this situation in future.
It may turn out to be non-issue. But would like to have clarification.
Thanks and Regards,
Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, D Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit