tinkerbell/hook

wget https://s.gianarb.it/hook/hook-master.tar.gz throws 404

Closed this issue · 17 comments

markjacksonfishing commented

Expected Behaviour

tar should be available

Current Behaviour

404

detiber commented

Quick workaround, s/hook/tinkie/g will get the last published image. I know @rawkode was working on getting a proper s3 bucket to upload to with the github automation (see #32), but haven't had a chance to followup on the current status recently...

rawkode commented

@detiber S3 bucket was handed over to @gianarb. You should be good to go :)

damdo commented

👋 Hey! I'm trying to get a link to a tarball for hook to test it out in place of OSIE but at the moment it's quite hard to find a link for it. Is there a plan for having an S3 bucket/ArtifactHub for hook?
Thank you for all your work!

PS:
Here is where I'm coping it from at the moment:
Screenshot 2021-08-09 at 17 13 59

nshalman commented

@thebsdbox Is there an updated link where folks should expect to find the latest build of Hook?

thebsdbox commented

In the releases! 🤩

damdo commented

Would it make sense to update the README here with a link to the latest release tarball?
i.e. https://github.com/tinkerbell/hook/releases/latest/download/hook-x86_64.tar.gz

I can open a PR if you think that would be sensible.
But we might want to stabilise the release process and the tarball structure/naming first, as from what I can understand (and please correct me if I'm wrong here @thebsdbox), the current latest release tarball build has been manually triggered via make while having this Pull Request branch checked out. Moreover the names of the artefacts contained in the tarball are not directly usable because of their naming and I had to rename them first:
i.e.:

 $ tar -xf ~/Downloads/hook-x86_64.tar.gz -C state/webroot/misc/osie/current
 $ cd state/webroot/misc/osie/current
 $ mv hook-x86_64-initrd.img initramfs-x86_64
 $ mv hook-x86_64-kernel vmlinuz-x86_64

I think we might want to first conclude and merge that PR and then optionally set up a GitHub Workflow (or equivalent) for building and releasing a tarball on git tag events (or similar).

What do you all think? Thanks.

thebsdbox commented

Yeah, i'm really behind at the moment juggling a few things i'll try and complete this bit of work tomorrow and stabilise the whole thing.

tstromberg commented

@thebsdbox - any update?

If you are still swamped: someone else could take this on if you describe what changes you were planning to make.

tstromberg commented

I'm still new here, but I'm not sure I understand what work is necessary to close this issue. Some questions:

  • Where is it documented that this particular URL should be hosting hook? I couldn't find any existing references to it.
  • Should we nuke the make dist target that pushes to s3://s.gianarb.it/hook/${GIT_VERSION}.tar.gz
  • @damdo's comment about adding a link seems reasonable.

At this point, does this issue boil down to fixing the "How to use hook with Sandbox" documentation in the README to be accurate again? I noticed it also references a current_versions.sh location which no longer exists.

thebsdbox commented

I'm currently (AS we speak) building the ARM release.. it just takes a long time on x86.

damdo commented

I can see that @thebsdbox has merged #70 GG! 🎉

Also we now have tarballs for both ARM64 and x86_64 in the latest release: https://github.com/tinkerbell/hook/releases/tag/5.10.57.

So to your points @tstromberg:

  • @damdo's comment about adding a link seems reasonable.

    With the new tarball release it should be easy to update the README link

  • Should we nuke the make dist target that pushes to s3://s.gianarb.it/hook/${GIT_VERSION}.tar.gz

    I think this is one for you @thebsdbox to weight in on, my 2c are that I think I would create a GitHub Actions workflow that (either through the Makefile or directly) can build and release a tarball on git tag events (or similar). To simplify the release process and offload it to CI rather than doing it manually on one's machine and uploading it to GH.
    i.e. by using something like https://github.com/softprops/action-gh-release or equivalent.
    We could then point the README (and sandbox?) always to the latest versioned/released tarballs like so: https://github.com/tinkerbell/hook/releases/latest/download/hook-x86_64.tar.gz

thebsdbox commented

I believe that this particular issue can be closed.. the problem that I think we have is that building a kernel with GitHub actions usually times out, especially with the cross compile builds. There already exists a PR from @detiber for this work.

nshalman commented

I believe that this particular issue can be closed.. the problem that I think we have is that building a kernel with GitHub actions usually times out, especially with the cross compile builds. There already exists a PR from @detiber for this work.

Any objections to closing this out, @markyjackson-taulia?

damdo commented

Hey @nshalman is the plan then to fix the release process by tracking it in #78 rather than here? Thanks.

nshalman commented

Hey @nshalman is the plan then to fix the release process by tracking it in #78 rather than here? Thanks.

@damdo if you think this ticket is still unresolved, then we should probably update the title and description. The sandbox now uses Hook out of the box, and I don't currently see mention of the URL in the title of this ticket in the README file.
Is there work that remains here that's separate from what's tracked in #78?

damdo commented

I agree with you here. There is no more mentions of this in the README and Hook is now the default in sandbox so no more need to do most of the things I was suggesting here: #45 (comment)
Also I see that you created this #88 which should track the remaining cleanup.
I think the rest of the work is covered and tracked by #78
So, yes, we should be able to close this if @markyjackson-taulia is happy :)

markjacksonfishing commented

Yes, close it and thank you