-
Notifications
You must be signed in to change notification settings - Fork 899
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
CI: migrate integration-test to GH actions #1969
Conversation
20f233f
to
603a568
Compare
603a568
to
3bed2c2
Compare
Nice, I agree with not implementing caching for now, that's something that can be added later. I'll have a better look later today. @aciba90 did you manage to test this on a fork or something? |
Thanks, @paride. The new workflow is being executed as part of the checks of this PR. See the |
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.
Looks great! Just one minor inline question.
.github/workflows/integration.yml
Outdated
- name: "Checkout #2 (for tools/read-version)" | ||
run: | | ||
git fetch --unshallow | ||
git remote add upstream https://git.launchpad.net/cloud-init |
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.
Do we actually need to add LP as a remote, especially given that it is added but never fetched?
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 was probably a relic / copy-paste, I have removed it and unified Checkout #1
and #2
in a single one.
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.
Nice and TIL about fetch-depth
, thanks!
b5be300
to
984efee
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.
One more inline comment/question.
.github/workflows/integration.yml
Outdated
runs-on: ubuntu-22.04 | ||
steps: | ||
- name: "Checkout" | ||
uses: actions/checkout@v3.0.0 |
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.
Here (and below, also for other actions), is there a reason for not going with @v3
instead of v3.x.y
, relying on the fact that compatibility shouldn't be broken in a given major version?
The official docs (e.g. https://github.com/actions/checkout) only specify the major.
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.
The only reason was to keep it consistent with the rest of workflows, but taking into account that they are official GitHub actions, I agree it is better to pin only major versions. Updated, thanks for pointing out that.
I will align the other workflows to this approach in a follow-up PR.
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.
Looks good, thanks!
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.
Looks good! Just curious, is this split into 2 separate jobs with the upload and download so that we can download the built deb when investigating failures? Or is there different reason for the split?
Thanks, @TheRealFalcon. That's one of the reason plus:
|
Proposed Commit Message
Additional Context
I have not ported the caching machinery for LXD images and chroots, as in my opinion it is not worth the complexity vs the gains, but I am open to other opinions.