-
Notifications
You must be signed in to change notification settings - Fork 346
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Giving ort its own build #2776
Giving ort its own build #2776
Conversation
Refer to this link for build results (access rights to CI server needed): |
This is a good idea. Happy to review once the merge conflicts are fixed. |
d4962ab
to
66dd0d9
Compare
conflicts have been fixed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything changed looks good (still need to test). Verified that all of the import path changes are correct by dragging/dropping traffic_ops/ort/atstccfg to traffic_ops_ort in Goland and letting it resolve references.
In addition to the files changed, the ORT path still needs to be changed in 2 files:
- tools/golang/unit-tests.sh
- docs/source/tools/atstccfg.rst
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to the TO build script changes mentioned, pkg
should now have a docker-compose pull
right before the docker-compose build
so people with an older prebuilt trafficcontrol/traffic_ops_builder
image do not get Traffic Ops build failures. That addition can be a separate PR but needs to be added before this PR is merged to avoid an unnecessary breaking change.
This PR has merge conflicts since #4557 was merged. |
96a71e7
to
3bb88f6
Compare
1974752
to
bbba3c1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good.
- Verified import changes
- No ORT-related files left behind (except
ToORTCheck.pl
, which is a TO extension) - Traffic Ops and Traffic Ops ORT RPMs build
- RPM file lists are identical, including source RPMs
- Disabling compiler optimizations for debug builds still works for Traffic Ops and Traffic Ops ORT
- Traffic Ops ORT unit tests pass (no need to test Traffic Ops, there were no TO code changes)
What does this PR do?
Pulls the build for a
traffic_ops_ort.*.rpm
out of the build for atraffic_ops.*.rpm
andmakes it its own build process. This won't affect a full build of the entire project, but
building Traffic Ops won't build the ort rpm anymore. That must be done explicitly with
the
traffic_ops_ort_build
job.Which TC components are affected by this PR?
What is the best way to verify this PR?
and then verify each generated
rpm
is valid by e.g. installing it and running any/all testsCheck all that apply