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.

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

x/build/cmd/relui: create GitHub releases #15966

Open
adg opened this issue Jun 6, 2016 · 13 comments
Open

x/build/cmd/relui: create GitHub releases #15966

adg opened this issue Jun 6, 2016 · 13 comments
Labels
Builders x/build issues (builders, bots, dashboards) FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@adg
Copy link
Contributor

adg commented Jun 6, 2016

GitHub has a "releases" feature that provides downloadable releases in a well-known location. We could make Go releases available via GitHub as well as our download page.

Assuming we want to do so, we could modify the release tool to create and populate those releases for us automatically.

But do we want to do this? What are the advantages? What are the disadvantages?

@adg adg added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jun 6, 2016
@adg adg added this to the Unplanned milestone Jun 6, 2016
@broady
Copy link
Member

broady commented Jun 6, 2016

I think I'd rather have a release API hosted on golang.org that provides a list of releases, tag names, binary URLs, etc.

@daaku
Copy link

daaku commented Jun 6, 2016

One advantage would be to provide an API via Github for tools like godeb to consume.

@ibnesayeed
Copy link

I would vote for utilizing GitHub's releases feature. In fact it is already being utilized but only the source files are released. The only overhead I can think of is the added step in the release process, which is not an issue since it will be automated using GitHub's Releases API. A few advantages that I can think of are following:

  • Familiarity for GitHub users who might expect binaries in releases tab in line with other projects on GitHub that distribute binaries.
  • Automatic support in existing tools and workflows that utilize GitHub's Releases API.
  • Better metrics for researchers who analyze data from GitHub repositories.
  • Some corporate firewalls might block golang.org, for them GitHub might serve as an alternative mirror.
  • Service downtime is not uncommon, it can happen to any host, having an alternate is always helpful.
  • Lots Of Copies Keep Stuff Safe.

Note: To sanitize automatic source releases on GitHub, .gitattributes file needs some changes that are discussed in CR-24741. If desired, I can send a fresh change to take care of the source release sanitation.

@ghost
Copy link

ghost commented Jul 17, 2016

@broady why not both?

@bradfitz
Copy link
Contributor

@broady, want to make a decision?

@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Mar 21, 2017
@broady
Copy link
Member

broady commented Mar 21, 2017

The only downside I can think of is that it makes it a little more difficult for analytics on downloads.
That said, we don't currently track downloads from golang.org/dl anyway, so it's not a huge downside.

I'll add this to the release tool. I don't see a pressing need for a separate API on golang.org.

The only thing to consider is whether to use @gopherbot's credentials or the end-user's GitHub credentials. I'd lean toward @gopherbot, and have gopherbot's token available from some endpoint gated by the "user-release" build token.

@codebien
Copy link

I'm looking into this, if you accept a PR I would submit it.
I think this is helpful because it enables to support the Github's notification type "Notify on Releases only" and also if you haven't yet implemented any type of analytics, you can get a basic downloads counter.

However, I would before define the expected behavior for the command.

  1. When the process should be invoked? Is it an exclusive operation or can it be executed during other processes like the current upload?
  2. Create the release and upload the artifacts on Github can be in the same unique operation or would you split them?
  3. Here you can find the fields required by the Github endpoint, what are the values do you expect to see there? I’m thinking something similar to:

    • name: the go version released (e.g go1.12/go1.12.6)

    • body: a short description with links to the Downloads and Release notes pages.
    • artifacts: just the versions available in Featured downloads on dl.
  4. @broady Can we use the Gopherbot's credentials?

@codebien
Copy link

@andybons Do you have any suggestion?

@jfcg
Copy link

jfcg commented Nov 9, 2020

Some corporate firewalls block anything from dl.google.com which currently hosts binary releases.

@dmitshur
Copy link
Contributor

dmitshur commented Nov 9, 2020

CC @golang/release.

@ZacWolf
Copy link

ZacWolf commented Mar 24, 2021

I would like to add that having a single format (i.e. schema to parse) for downloading/upgrading binaries from (vs having to build everything), is a huge advantage to many folks. I've already written my own batch job that automates downloading new releases from GitHub, so GO has become a one-off that I have to remember to manually check.

@Al2Klimov
Copy link

I think this is helpful because it enables to support the Github's notification type "Notify on Releases only"

That would be an absolute killer feature for me as a Go dev. I'd get an eMail automatically (wouldn’t have to check manually) triggering me to add the new Go version (and the new archs) to my apps' CI matrices.

@adg
Copy link
Contributor Author

adg commented Aug 25, 2021

@Al2Klimov The golang-announce mailing list should serve that purpose for you.

@dmitshur dmitshur changed the title x/build/cmd/release: create GitHub releases x/build/cmd/relui: create GitHub releases May 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Builders x/build issues (builders, bots, dashboards) FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests