-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Github action for jaeger packages and docker image #2740
Github action for jaeger packages and docker image #2740
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2740 +/- ##
=======================================
Coverage 95.83% 95.83%
=======================================
Files 217 217
Lines 9656 9656
=======================================
Hits 9254 9254
Misses 331 331
Partials 71 71
Continue to review full report at Codecov.
|
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.
Release part is still pending. Looking at it, I think we need to use https://github.com/actions/upload-release-asset action but not quite sure how to make it work without changing our current release process.
well, (a) the current release process is non-functional since Travis refuses to run out jobs, and (b) do you have reasons to suspect that scripts/travis/package-deploy.sh
would not work?
- Build tar file for jaeger components Signed-off-by: Ashmita Bohara <[email protected]>
Sorry my bad in not explaining my point properly. This PR doesn't add changes equivalent to https://github.com/jaegertracing/jaeger/blob/master/.travis.yml#L93-L104 part of the travis configuration. For that we need to use https://github.com/actions/upload-release-asset But I am confused about how to make it work equivalently because of this |
One option would be to make the whole workflow contingent on the presence of a tag, but then we'd miss any compile errors due to arch differences. So the other alternative is to do what the upload to docker script is doing, i.e. check the tag explicitly and skip the upload of bundles if no tag. Then the workflow will always run. |
Do you recommend having a new github action like ci-release.yml which will run only when the tag is pushed ?
|
Also looking at the example of README of https://github.com/actions/upload-release-asset it seems like it depends on another action https://github.com/actions/create-release (this part we do manually as part of our current release process) I was thinking maybe we can probably set |
We don't want to create a release from actions, because out workflow is (1) create release manually, (2) use CI to upload artifacts into it. It doesn't look like upload-release-asset depends on create-release, but it does need upload_url for the release (don't know why GH makes it so hard). We could use this one instead https://github.com/bruceadams/get-release, although I would've preferred an official one. There's an open issue actions/upload-release-asset#34 |
looks like this could be used |
Sure Yuri, Thank you for the feedback. I will try out as you suggested in my forked repo. |
Signed-off-by: Ashmita Bohara <[email protected]>
Signed-off-by: Ashmita Bohara <[email protected]>
I tried updating the PR as per your comments. Since the GitHub Action https://github.com/actions/upload-release-asset doesn't support uploading multiple files in one task by using regex, I had to use https://github.com/marketplace/actions/upload-files-to-a-github-release action instead. I tried this PR in my jaeger's fork by creating a release manually (https://github.com/Ashmita152/jaeger/releases/tag/v1.25.0). It triggered the ci-release GitHub Action whose run you can find here: https://github.com/Ashmita152/jaeger/runs/1798106742?check_suite_focus=true |
Signed-off-by: Ashmita Bohara <[email protected]>
Signed-off-by: Ashmita Bohara <[email protected]>
Thank you for the feedbacks Yuri. Those were nice catches. I have updated the PR removing those. |
Signed-off-by: Ashmita Bohara <[email protected]>
I have created a new release in my forked repo: https://github.com/Ashmita152/jaeger/releases/tag/v1.35.0 and CI for the release job is: https://github.com/Ashmita152/jaeger/runs/1798332218?check_suite_focus=true This time the BRANCH is populating properly:
|
|
||
- name: Fetch git tags | ||
run: | | ||
git fetch --prune --unshallow --tags |
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.
why do we need this step when building binaries?
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.
also, when we do need tags, can we achieve the same effect with this setting?
# Number of commits to fetch. 0 indicates all history for all branches and tags.
# Default: 1
fetch-depth: ''
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 think if we want to pull tags as part of checkout
action, only option from my understanding is to set fetch-depth: 0
which will also fetch all the commit history of all branches which will increase build time. I'm unable to find an option for just pulling the tags without commit history.
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.
maybe it's worth creating a PR for the official action to add a new parameter like tags:
Signed-off-by: Ashmita Bohara <[email protected]>
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.
Thanks!
@Ashmita152 seeing some odd https://github.com/jaegertracing/jaeger/runs/1803971666?check_suite_focus=true#step:6:9
|
Hi @yurishkuro
|
yeah, i think it would be neat if we could build them in parallel |
Signed-off-by: Ashmita Bohara [email protected]
Which problem is this PR solving?
Short description of the changes