-
Notifications
You must be signed in to change notification settings - Fork 30
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
Would you like an C.I. to test the builds? #22
Comments
I tried Travis already (see dc3b758), the problem is that the build takes too long and so it is not compatible with Travis time limits. |
Ah yes, it does take a long time. Let me see what the restrictions are around GitHub Actions as I've forked it over there on my accounts. |
I'm making some good headway with Github Actions (Github's native, free, unlimited CICD tool). https://github.com/features/actions I'll start on the usbarmory builds this weekend or next week. |
Looks like Github Actions gives you up to 6 hours to run! https://help.github.com/en/articles/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes Almost done. I'm getting an error running on Ubuntu 18.04 and compiling for the Mark II. Notice Mark I passes though! Woohoo! Could you take a look? The errors are in the https://github.com/eduncan911/usbarmory-debian-base_image/runs/257866845 However, on the https://github.com/eduncan911/usbarmory-debian-base_image/runs/257866843 Maybe no one has built this on Ubuntu 18.04? I only have options of Ubuntu 16.04 (too old gcc I ran into with u-boot) and Ubuntu 18.04 (giving the errors above). Also, could you give me a set of checks and/or processes to perform AFTER In addition, GitHub Actions can do anything - I can sign the build and make a full Release automatically (if pushing to master obviously). That would involve a private signing key though. Maybe you can upload a short-expiring sub-key (GitHub now has "Secrets" for uploading things like this). I could also create a bash script you can run on your local machine to push a 24 hour signing sub-key if you want directly to GitHub (which is what I would do if it was me, before I "merge" any PR to master - run bash script, merge). |
The README highlights some keys that need to be imported in the pre-requisites section, have you imported that in your action? |
Thanks @abarisani. Yep, I was importing but had a bug in my retry logic (as PGP keyservers are unreliable). Fixed and now they always get both keys. Switching to I'll clean up the branch and will submit a PR. However, next steps is that you need to file a request to get access to Github Actions to enable it for your Github Org or it will never work: https://github.com/features/actions More info... I was previously building each
Besides, having so many steps would actually make things more fragile if we were ever to change the Makefile, which I'm assuming is still in flux? :) |
Thanks for all the effort! I just signed up for Actions beta for our org, we will review your commits while we wait on that! Cheers. |
Ok, I now have Actions enabled. |
I wonder if something like this can be used to directly upload to a new release? https://github.com/JasonEtco/upload-to-release/blob/master/upload-to-release It would be nice if the release would remain a draft, so that we can download and check the image and manually set it to non draft (the linked script does the opposite). |
There already an action for it.
https://github.com/eduncan911/usbarmory-debian-base_image/blob/b6d507b4f9f91e13e5989f270b3c683914e103f2/.github/workflows/tag-to-release.yml#L96-L104
Though, I currently have an issue open to see if they would do the work
first: actions/upload-release-asset#4
I thought you wanted to verify each binary first? :)
The biggest hold up for me to submit a PR for it are your rich-text heavy
detailed Release Notes. I've come up with a way to template-and-parse
release notes; just, I haven't had the time to work on it yet.
But yes, it can build all 3 versions. Which, is kind of a problem...
I added a target to the Makefile for releases, which creates the sha256 of
each file:
https://github.com/eduncan911/usbarmory-debian-base_image/blob/b6d507b4f9f91e13e5989f270b3c683914e103f2/Makefile#L241-L243
However, this creates 12 files to upload!
I wanted to ask if you'd be willing to drop the XZ compression? We'd then
build and upload only 6 files then.
…On Sun, Oct 20, 2019 at 6:45 PM Andrea Barisani ***@***.***> wrote:
I wonder if something like this can be used to directly upload to a new
release?
https://github.com/JasonEtco/upload-to-release/blob/master/upload-to-release
It would be nice if the release would remain a draft, so that we can
download and check the image and manually set it to non draft (the linked
script does the opposite).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#22>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAZUFBMQ6SS3E3RZ5AVN23QPTNSJANCNFSM4I6UBQVQ>
.
|
I do want to verify each binary first, which is why I mentioned that I would be happy with upload to draft releases only. Because this allows me to download the published file on the draft release (which won't be public), validate it and then mark manually the release as non-draft. Does that make sense? I'd like to peak only two releases, imx53 on uSD and imx6ULL on uSD, do you think this is feasible? Thanks! |
Oh yes, easy!
The only hold up is no current action supports a body not multiple
attachments.
But if you want just two releases, I can specify just those files for now
to upload pretty quick. :)
What about xz? Keeping them?
mark-one-usd-...zip
mark-one-usd-...zip.sha256
mark-one-usd-...xz
mark-one-usd-...xz.sha256
mark-two-usd-...zip
mark-two-usd-...zip.sha256
mark-two-usd-...xz
mark-two-usd-...xz.sha256
That's 8 files. If we drop xz, then it's only 4 files.
…On Mon, Oct 21, 2019, 5:35 AM Andrea Barisani ***@***.***> wrote:
I do want to verify each binary first, which is why I mentioned that I
would be happy with upload to *draft* releases only. Because this allows
me to download the published file on the draft release (which won't be
public), validate it and then mark manually the release as non-draft. Does
that make sense?
I'd like to peak only two releases, imx53 on uSD and imx6ULL on uSD, do
you think this is feasible?
Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#22>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAZUFDTOLID27ACUSPR6C3QPVZVXANCNFSM4I6UBQVQ>
.
|
Ideally it would be one release with two attachments, but if that's not possible then two separate releases is fine. I'd keep both .zip and .xz files consistently with previous releases. |
Oh, it can be anything you like. One release with multiple attachments (8
attachments). Two releases.
One release is best I think. The large number files in the one release is
for the sha256 checksum I'm attaching, for each file. I think it's best to
embed the file next to the release files. Makes for automated parsing and
verification scripts.
Question: did you notice I've slightly renamed the filenames? I had to add
"usd" and "emmc" to the naming convention so they could be separate in the
same build directory to upload from. It's all in that PR above I am testing
with.
I'm travelling today for work so I'll try to tinker with it on the plane
to/from.
…On Mon, Oct 21, 2019, 9:08 AM Andrea Barisani ***@***.***> wrote:
Ideally it would be one release with two attachments, but if that's not
possible then two separate releases is fine. I'd keep both .zip and .xz
files consistently with previous releases.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#22>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAZUFBLYJ2BU4JG55JFJATQPWSUHANCNFSM4I6UBQVQ>
.
|
I was thinking of one release with just 2 .xz files (uSD for mark-one and mark-two) and SHA256s, but if there are no constraints on Github why not making all valid combinations (uSD for mark-one and mark-two, eMMC for mark-two, SHA256 file and .xz/.zip for all) ? |
Heh, that's what I was originally proposing: attach all to one release, including sha hash files. :) I'll try to whip up something this week. Note one restriction with GitHub Actions: their triggers for builds are kind of limited. So I was going to trigger a "Release" purely from a Tag. You make a Tag, and push the tag up, and it will trigger a DRAFT release build and push all files up. Note x2: since I have to build all of this in one pipeline, I have to do it synchronously. That is, one at a time. So the build will take about 1.5 to 2 hours to produce the final Release. Btw, hit me on keybase.io/eduncan911 if like. Or another messenger (PM twitter as well) |
Ok, and sorry for the ping-pong. I was thinking out loud ;). |
With the addition of the Dockerfile in #21 , I can put together a Travis or maybe even a Github Tasks build environment to test for and report the state of
master
, and all PRs.I have GitHub Actions enabled in my account; however, I think everyone has to request enrollment with Github.
Let me know and I will try to whip it up. Most likely will test all 3 build targets of the Makefile, and test that the files exists with no build errors.
Note: an Administrator will have to setup the tasks and join it to Travis or alike. I'll try to keep the instructions short and simple for the Assignee here to minimize the work.
The text was updated successfully, but these errors were encountered: