Skip to content

CRON job to trigger daily build of ros2 images#348

Merged
mikaelarguedas merged 4 commits intoosrf:masterfrom
mikaelarguedas:docker_cron_job_to_pr
Jan 23, 2020
Merged

CRON job to trigger daily build of ros2 images#348
mikaelarguedas merged 4 commits intoosrf:masterfrom
mikaelarguedas:docker_cron_job_to_pr

Conversation

@mikaelarguedas
Copy link
Copy Markdown
Contributor

ros2 images have not been rebuilt since Dec 4th (20 days ago).
It was suggested in the past to have a cron job to trigger these builds daily to not rely on the currently flaky setup. The PR for it has been blocked for a while #312

This PR implements a cron job using Github Actions thus allowing us to use it without extra permissions given to a third party app.

How it compares to #312:

  • the secrets have to be defined in this repo. They are encrypted by github and filtered out of the logs
    • cons:
      • any matching string in the logs will be redacted, so it could actually leak password if the same string is printed to the logs from code (though unlikely). I believe the logs are not public, so leaking is prevented
      • Logs are not public?
  • the images are built in the actions and not on dockerhub:
    • pro:
      • we get notified on build failure
      • the job starts instantly
    • cons:
      • slower (maybe?) as pulling, building and pushing will require some bandwidth and latency is likely lower on dockerhub
      • I'm discovering github actions and hopefully things can be optimized and improved later on

Leaving this in draft for a couple days the time it proves to run reliably at https://github.com/mikaelarguedas/docker_images/actions

@ruffsl
Copy link
Copy Markdown
Member

ruffsl commented Dec 23, 2019

I see you've opted to have the docker engine in the CI build in image, instead of that of the automated registry. One reason in #312 that I opted to use the registry API to trigger the build was that it would subsequent trigger any automated repo build pointed at osrf/ros2 repo upon success. Could you verify that pushing remotely to the registry instead still triggers downstream docker hub repos to rebuild?

@mikaelarguedas
Copy link
Copy Markdown
Contributor Author

was that it would subsequent trigger any automated repo build pointed at osrf/ros2 repo upon success

Oh right, it's definitely a potential downside, I havent tried it but I would expect dockerhub to trigger downstream repo only from successful automated builds (and not from image pushes).
I'll give it a shot soon and report here.

If we end up having to back to triggering them instead of pushing them, just saw that triggering nightly yeasterday did not trigger the downstream nightly-rmw* images .. So we'll need to trigger all images from the cron job.

@ruffsl
Copy link
Copy Markdown
Member

ruffsl commented Dec 23, 2019

just saw that triggering nightly yeasterday did not trigger the downstream nightly-rmw* images

Hmm, that was not what I've seen in the past, as this post_push hook was working when I setup the the docker hub repo settings. You triggered the nightly tag, yet on build/push completion by docker hub, the webhook did not trigger/cascade to build the next tag?

#!/bin/bash
curl -H "Content-Type: application/json" \
--data '{"docker_tag": "nightly-rmw"}' \
-X POST ${POST_PUSH_TRIGGER}

@ruffsl
Copy link
Copy Markdown
Member

ruffsl commented Dec 23, 2019

Looks like the trigger api URL has migrated from https://cloud.docker.com/api/build/v1/source/.../call to https://hub.docker.com/api/build/v1/source/.../call.

I've updated the URL in the POST_PUSH_TRIGGER for the BUILD ENVIRONMENT VARIABLES.

@ruffsl
Copy link
Copy Markdown
Member

ruffsl commented Dec 23, 2019

Also, looks like the github link to the osrf/docker_images repo has been unset. It doesn't seem like I have the github permissions to re-link it: ping @tfoote or @nuclearsandwich

image

This perhaps explains why my fork with the CircleCI cron job (using #312) triggering was ineffective while still correctly calling the API daily.

https://circleci.com/gh/ruffsl/docker_images/tree/master

@mikaelarguedas
Copy link
Copy Markdown
Contributor Author

Also, looks like the github link to the osrf/docker_images repo has been unset.

This seem to be fixed
Screenshot from 2019-12-24 09-15-15

@mikaelarguedas
Copy link
Copy Markdown
Contributor Author

mikaelarguedas commented Dec 24, 2019

was that it would subsequent trigger any automated repo build pointed at osrf/ros2 repo upon success

It actually works, downstream repos get triggered when new mages are pushed 🎉. tested on this repo

(unrelated to the push/build on dockerhub)Note that it works only with repos where the base image is explicitly set: FROM osrf/ros2:devel. Doesn't work for files that have a configurable base image

ARG FROM_IMAGE=osrf/ros2:devel
FROM $FROM_IMAGE

One possible downside of this approach if that the build logs will not be on docker hub anymore. Not a big bummer though


I also thought a bit about the triggering approach and a few questions come up compared to this github actions approach:

  • How would we confirm that the build trigger worked? (to avoid surprises like CRON job to trigger daily build of ros2 images #348 (comment))
  • How would we get notified if the automated build fails? (there's no webhook for build failure on DockerHub).
    • Potential solution: We can enable email notifications on build failure. These are per organization and not per repo, so we'll receive email for any failed builds on the osrf org (currently the only one failing is sros). It may be worth enabling regardless of the approach we take.

@mikaelarguedas
Copy link
Copy Markdown
Contributor Author

Potential solution: We can enable email notifications on build failure. These are per organization and not per repo, so we'll receive email for any failed builds on the osrf org (currently the only one failing is sros). It may be worth enabling regardless of the approach we take.

#350 fixes the build of the sros image

@mikaelarguedas mikaelarguedas marked this pull request as ready for review December 29, 2019 09:46
Signed-off-by: Mikael Arguedas <[email protected]>
@mikaelarguedas
Copy link
Copy Markdown
Contributor Author

Follow-up of offline discussion:

  • Email notifications on dockerhub have been enabled after thumbsup from Tully
  • Made a change to go back to triggering builds on dockerhub insteal of building in github actions mikaelarguedas@88e3569

I'll let it run for a day or 2 before forcepushin the change to this branch

@ruffsl
Copy link
Copy Markdown
Member

ruffsl commented Jan 17, 2020

I'll let it run for a day or 2 before forcepushin the change to this branch

Ok, I've just now disabled the CircleCI on my fork to check yours is working fine.

@mikaelarguedas
Copy link
Copy Markdown
Contributor Author

Ok, I've just now disabled the CircleCI on my fork to check yours is working fine.

👍 Seems to have ran successfully today.

Regarding the implementation. I couldn't get curl to expand $dockerTag if it was provided as an env var in the build matrix. So I had to duplicate the jobs... Now this workflow has 2 jobs one to trigger the devel image and one for the nightly one

Signed-off-by: Mikael Arguedas <[email protected]>
@mikaelarguedas
Copy link
Copy Markdown
Contributor Author

mikaelarguedas commented Jan 22, 2020

Relevant secret added to this repo.

This is now ready for review

@mikaelarguedas mikaelarguedas requested a review from ruffsl January 22, 2020 11:06
@mikaelarguedas mikaelarguedas changed the title CRON job to build and publish ros2 images CRON job to trigger daily build of ros2 images Jan 22, 2020
Comment thread .github/workflows/cron.yaml Outdated
Copy link
Copy Markdown
Member

@ruffsl ruffsl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just a nitpick that might help release the nightly images sooner together. If it gets complex for actions to have different cron job times for the two, then nevermind.

@mikaelarguedas mikaelarguedas merged commit b5f4849 into osrf:master Jan 23, 2020
@mikaelarguedas mikaelarguedas deleted the docker_cron_job_to_pr branch January 23, 2020 10:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants