Skip to content
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.

Sign up for GitHub

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

Jump to bottom

(WIP) add goreleaser basic config #1022

Closed
wants to merge 1 commit into from
Closed

(WIP) add goreleaser basic config #1022

wants to merge 1 commit into from

Conversation

sebastianwebber
Copy link

This PR adds the basic config for GoReleaser build, compact, package rpm and deb, and a docker image.

Due to the CGO dependencies the build is only made on Linux 64 bits. I can work on alternatives for i386 if that is something needed. But for OSX I need to check that problem on another PR.

About the docker image, I think that the ideal is that we use a distro less based image WDYT?

Should I add the changes for the Travis CI too?

related with #715

@sebastianwebber
feat: add goreleaser basic config
c55d7cf 
this commits adds the basic config for goreleaser build, compact,
package rpm and deb, and docker image.
@sebastianwebber sebastianwebber marked this pull request as draft August 20, 2020 02:08
@sebastianwebber
Copy link
Author

sebastianwebber commented Aug 20, 2020 •
edited
Loading

set this as a draft until solve the docker base image.

@TomSweeneyRedHat
Copy link
Member

@sebastianwebber thanks for putting this together. This all LGTM, but I've practically zero knowledge of goreleaser so definitley want other eyes here. @xyphr or @m86194 thoughts?

I'd also add the changes to the CI. @cevich and @edsantiago any goreleaser experience?

@tandeday
Copy link

tandeday commented Aug 20, 2020 via email

@sebastianwebber
Copy link
Author

sebastianwebber commented Aug 20, 2020 •
edited
Loading

@sebastianwebber thanks for putting this together. This all LGTM, but I've practically zero knowledge of goreleaser so definitley want other eyes here. @xyphr or @m86194 thoughts?

No worries.

I case that you want to try it, just run:

goreleaser --snapshot --skip-publish --rm-dist

the output should be something like this:

➜ goreleaser --snapshot --skip-publish --rm-dist
   • releasing...     
   • loading config file       file=.goreleaser.yml
   • running before hooks
   • loading environment variables
   • getting and validating git state
      • releasing v1.1.0, commit c55d7cf38b63c9829b6353412b985d65f9c77478
      • pipe skipped              error=disabled during snapshot mode
   • parsing tag      
   • setting defaults 
      • snapshotting     
      • github/gitlab/gitea releases
      • project name     
      • building binaries
      • creating source archive
      • archives         
      • linux packages   
      • snapcraft packages
      • calculating checksums
      • signing artifacts
      • docker images    
      • artifactory      
      • blobs            
      • homebrew tap formula
      • scoop manifests  
      • milestones       
   • snapshotting     
   • checking ./dist  
      • --rm-dist is set, cleaning it up
   • writing effective config file
      • writing                   config=dist/config.yaml
   • generating changelog
      • pipe skipped              error=not available for snapshots
   • building binaries
      • building                  binary=/home/seba/projetos/pessoal/skopeo/dist/linux_linux_amd64/skopeo
   • archives         
      • creating                  archive=dist/skopeo_v1.1.0-next_Linux_x86_64.tar.gz
   • creating source archive
      • creating source archive   file=skopeo-v1.1.0-next.tar.gz
   • linux packages   
      • creating                  file=dist/skopeo_v1.1.0-next_linux_amd64.deb
      • creating                  file=dist/skopeo_v1.1.0-next_linux_amd64.rpm
   • snapcraft packages
   • calculating checksums
      • checksumming              file=skopeo_v1.1.0-next_linux_amd64.rpm
      • checksumming              file=skopeo_v1.1.0-next_Linux_x86_64.tar.gz
      • checksumming              file=skopeo-v1.1.0-next.tar.gz
      • checksumming              file=skopeo_v1.1.0-next_linux_amd64.deb
   • signing artifacts
   • docker images    
      • building docker image     image=containers/skopeo:v1.1.0
      • pipe skipped              error=publishing is disabled
   • publishing       
      • blobs            
         • pipe skipped              error=blobs section is not configured
      • http upload      
         • pipe skipped              error=uploads section is not configured
      • custom publisher 
         • pipe skipped              error=publishers section is not configured
      • artifactory      
         • pipe skipped              error=artifactory section is not configured
      • docker images    
         • pipe skipped              error=publishing is disabled
      • snapcraft packages
         • pipe skipped              error=publishing is disabled
      • github/gitlab/gitea releases
         • pipe skipped              error=publishing is disabled
      • homebrew tap formula
         • token type                type=github
      • scoop manifests  
         • pipe skipped              error=publishing is disabled
      • milestones       
         • pipe skipped              error=publishing is disabled
   • release succeeded after 8.25s

Please note that there is some limitations to cross-compiling since we have a few C dependencies. I'm not sure if it will be possible to generate OSX binaries or generate a 32 bits version. If 32bits is mandatory please let me know.

@cevich
Copy link
Member

cevich commented Aug 21, 2020

the CI. @cevich and @edsantiago any goreleaser experience?

None whatsoever, don't even know how to spell it. Though I appreciate the heads up given the significance of the feature.

I don't remember the state of CI on this repo., @sebastianwebber what were you thinking in terms of updating it?

Any thoughts on publishing the outputs? I have a good handle on most of the security-models involved. I'll help with providing tokens or credentials as needed, if that's helpful.

@sebastianwebber
Copy link
Author

the CI. @cevich and @edsantiago any goreleaser experience?

None whatsoever, don't even know how to spell it. Though I appreciate the heads up given the significance of the feature.

I don't remember the state of CI on this repo., @sebastianwebber what were you thinking in terms of updating it?

I can do that, even fix the current docker image, and integrate with the current build with Travis CI.

Any thoughts on publishing the outputs? I have a good handle on most of the security-models involved. I'll help with providing tokens or credentials as needed, if that's helpful.

I think that, for now, set the builds on the release page will be a nice start.

I will extend the changes to support this and get back to you.

@cevich
Copy link
Member

cevich commented Aug 21, 2020

Fantastic! Really happy to see things modernize here. Please let me know if you need help with anything.

@rhatdan
Copy link
Member

rhatdan commented Aug 24, 2020

I would prefer commends use "container image" rather then "docker image"...

@mtrmac
Copy link
Contributor

mtrmac commented Aug 24, 2020

Hi. Thanks for the work!

The original conversation in #715 was centered around Windows support, where we have little expertise and any way to release binaries would help.

As for Linux builds, I’m not quite sure that introducing a tool that apparently few people understand, and moving the burden of maintaining them to this project, makes that much sense.

Of course, we all can learn new tools; but the above concerns are not very tooling-related.

@TomSweeneyRedHat could there be a benefit for building the “unstable” image? I can’t remember how, and how frequently, that one is being built now.

@TomSweeneyRedHat
Copy link
Member

@mtrmac I think your "unstable" image is our "upstream" image (quay.io/skopeo/upstream:latest). We build that along with quay.io/skopeo/stable:latest and quay.io/skopeo/testing:latest once a day, assuming the cron process that I've set up doesn't have failures. Currently, that's configured to fire off at 9:00 a.m. Eastern every day. The Dockerfiles that run those live here fwiw.

@sebastianwebber
Copy link
Author

Hey all, sorry for the delay.

The original conversation in #715 was centered around Windows support, where we have little expertise, and any way to release binaries would help.

Since the code has some C dependencies, like libdevmapper1 and CGO I'm not sure it will be possible to use go-releaser to cross-build windows binaries. There is a note about that on its docs: https://goreleaser.com/limitations/cgo/

As for Linux builds, I’m not quite sure that introducing a tool that apparently few people understand, and moving the burden of maintaining them to this project, makes that much sense.

That depends if this is something that we want to do with this project. Go applications are commonly distributed on the GitHub releases page, like the goreleaser page or a small project that i'm working on.

When I suggested use goreleaser builds, I was thinking to make it easier get the binaries on the releases page. GOReleaser can build and package golang based builds in so many ways that makes it easier to publish the changes on this repo.

Sorry if I misunderstood something.

Please let me know if you guys wanna keep working on this PR.

@rhatdan
Copy link
Member

rhatdan commented Nov 17, 2020

You should be able to use a buildtag to remove the devicemapper support. We currently can build skopeo for Windows and MacOS. I am fine with getting Skopeo out to more sites where it is easer for people to access it.

@abergmeier
Copy link

Due to the CGO dependencies the build is only made on Linux 64 bits.

Sorry for getting OT - but how much work would it be to replace CGO with pure Go deps?

Looked at using skopeo a year ago and for me CGO was a show stopper.

@rhatdan
Copy link
Member

rhatdan commented Feb 23, 2021

The only CGO dependency can be eliminated by building with a buildtag, as long as you don't use devicemapper storage back end, which almost no one does.

@github-actions
Copy link

github-actions bot commented Jun 5, 2021

A friendly reminder that this PR had no activity for 30 days.

@lsm5 lsm5 added the volunteers-wanted Issues good for community/volunteer contributions label Jun 7, 2021
@lsm5
Copy link
Member

lsm5 commented Sep 20, 2021

I think this can be closed? @mtrmac @rhatdan wdyt?

@mtrmac
Copy link
Contributor

mtrmac commented Sep 20, 2021

I think so. We were discussing using a new tool for Windows support; introducing it for Linux, where we already have some working solutions and we aren’t familiar with this tool, seems not worth it.

@lsm5 lsm5 closed this Sep 20, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
locked - please file new issue/PR stale-pr volunteers-wanted Issues good for community/volunteer contributions
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
8 participants
@sebastianwebber @TomSweeneyRedHat @tandeday @cevich @rhatdan @mtrmac @abergmeier @lsm5