Remove manpage generation from Tito build #11183
Conversation
If a Tito build is done from a commit checked into origin/master, the man pages will by definition be up-to-date, as verifying that is a prerequisite for pull request acceptance. Signed-off-by: Steve Kuznetsov <[email protected]>
|
I think this is in there for downstream projects like OSE. Right @tdawson? |
|
That was put in there because of #9407 |
|
Hmm, I think in Origin we will want to not generate them since it's "extra" work - could we make it optional? Or do you think we should have a command to generate them like the one in |
|
I should mention the man page content downstream is all different because of the changes to the content, 'OSE' or 'OCP' versus 'Origin' in pretty much every man page. In the past we've not blocked merges on the test but we probably should, building the manpages in the RPM build process was our safety net against those problems. What's your concern with leaving this step in the rpm build process? Time? |
This is understood, but surely when you run the manpage generation in the merge queue for that project they are generated correctly, right?
Yes, once my tool is put into use for our CI system, this |
This is unsettling to me. |
|
So, I've been pretending I know what's going on with the "merge queue", and at this point I'm going to stop doing that and ask questions. When exactly do these man pages get generated if not in the rpm? If I do a merge does this do more than just merge? I know it tests. But is it also twiddling bits behind my back? For all of the origin 1.3 / ose 3.3 the test queue, and thus the merge queue was always broken. We didn't do a single merge the whole time, it was all manual testing and then a manual merge (push the big green button) For origin 1.4 / ose 3.4 we've fixed the testing, and so we are now doing merge's. |
|
Tagging a PR with the merge tag will fire off a Jenkins job that spawns EC2 instances in which a number of tasks are done, one of which is similar to the |
|
Speaking of which, let's be careful when we throw around that tag :) |
|
Rosie please no! |
|
Sorry about putting that in the comments. I get to typing and totally forgot what happens when you type that. Thanks for the explanation. I didn't know the merge did that. I'll be doubly sure to make sure the 1.4 / 3.4 get a proper merge. As for the original request, I just checked and it looks like for 1.4 / 3.4 the man pages are being updated properly during "the merge" So I have no problem removing this step. |
|
@tdawson since the specfile is grabbing the documentation from |
|
You are correct, that will do it. Give it a merge. |
|
[merge] this time I mean it @openshift-bot |
|
[Test]ing while waiting on the merge queue |
|
Evaluated for origin test up to 3f2bf48 |
|
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/9665/) |
|
@openshift-bot, the last build failed from the following flakes:
re[merge] |
|
@openshift-bot, the last build failed from the following flakes:
re[merge] |
|
Evaluated for origin merge up to 3f2bf48 |
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/9704/) (Image: devenv-rhel7_5140) |
If a Tito build is done from a commit checked into origin/master,
the man pages will by definition be up-to-date, as verifying that
is a prerequisite for pull request acceptance.
Signed-off-by: Steve Kuznetsov [email protected]