-
Notifications
You must be signed in to change notification settings - Fork 100
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
Make the doc_independent_docker_build a little more generic. #846
Conversation
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.
I don't have any real concerns here. Nothing that would need a staged rollout as long as the config change already being discussed gets implemented.
'git -C $WORKSPACE/repositories/%s log -n 1' % doc_repository_name, | ||
'rm -fr $WORKSPACE/repositories/%s/.git' % doc_repository_name, |
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.
Any context on why this was done to begin with?
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 has been there since the doc_independent_docker_job was added. I can only guess that this was a copy from the doc_independent_job, which does the same thing. Maybe it is an attempt to limit the number of Docker layers? I don't really know.
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.
It does occur to me that some of the tools which recurse over projects may stray into .git metadata if left unchecked but I'm okay giving this a shot and monitoring in production. c204239 is the commit which introduced this for the doc_independent job and appears to be part of a generic cleanup approach. The commit message does not indicate a motivation.
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.
That's true, I think we'll have to monitor it. The good news is that this job is used for very few jobs currently (only index at the moment, I believe), so any breakage will be limited in scope.
All right, I think I've addressed all of the open comments. You can see the job that results from using this code along with the configuration at https://github.com/ros-staging/ros_buildfarm_config/blob/staging/ros2-documentation-build.yaml here: https://build.test.ros2.org/job/doc_ros2-documentation/ @nuclearsandwich @cottsay please take another look when you get a chance. Thanks. |
'git -C $WORKSPACE/repositories/%s log -n 1' % doc_repository_name, | ||
'rm -fr $WORKSPACE/repositories/%s/.git' % doc_repository_name, |
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.
It does occur to me that some of the tools which recurse over projects may stray into .git metadata if left unchecked but I'm okay giving this a shot and monitoring in production. c204239 is the commit which introduced this for the doc_independent job and appears to be part of a generic cleanup approach. The commit message does not indicate a motivation.
In particular: 1. Allow the user to specify the branch to checkout on the source repository. 2. Allow the doc_independent_docker_build to upload either via the publish-over-git publisher, or via an rsync script. Signed-off-by: Chris Lalancette <[email protected]>
Signed-off-by: Chris Lalancette <[email protected]>
Signed-off-by: Chris Lalancette <[email protected]>
Signed-off-by: Chris Lalancette <[email protected]>
63fcdae
to
82f5de7
Compare
All right, going ahead and merging this. Thanks for the reviews. |
In particular:
source repository.
via the publish-over-git publisher, or via an rsync script.
Signed-off-by: Chris Lalancette [email protected]
This functionality is needed for uploading ros2_documentation to docs.ros.org. I've tested this functionality up to the upload sequence; the test buildfarm I am working on doesn't actually have the correct credentials, so I can't do an end-to-end test. I'll point out a few things of interest inline.