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

support github release :body #155

Open
mockitoguy opened this Issue Jul 8, 2014 · 24 comments

Comments

Projects
None yet
@mockitoguy

mockitoguy commented Jul 8, 2014

Hey guys,

Thanks for awesome tooling! Please consider adding support for :body when creating release in github.

http://rdoc.info/gems/octokit/Octokit/Client/Releases#create_release-instance_method
https://github.com/travis-ci/dpl/blob/master/lib/dpl/provider/releases.rb#L74

Cheers :)

@Joshua-Anderson

This comment has been minimized.

Member

Joshua-Anderson commented Jul 14, 2014

👍 I can work on this in the next few days

@mockitoguy

This comment has been minimized.

mockitoguy commented Jul 14, 2014

Awesome. Thanks :)

@Joshua-Anderson

This comment has been minimized.

Member

Joshua-Anderson commented Jul 16, 2014

I'm not sure this is a good option anymore. Most of the time, we upload to a existing release which already has a body, so we can't set it.

However, if the creator uses a light git tag, it doesn't show up as a github release, so we create a new release. In this situation, we could potentially set the body.

I think that it would be really confusing for the user to have the body option that they specify not applied in some cases but occasionally in others. Secondly, you can easily edit the body yourself in the github ui.

@mockitoguy

This comment has been minimized.

mockitoguy commented Jul 16, 2014

Oh I see.

My use case was continuous deployment. I don't really want to host downloadables with git releases. I just want some place to keep release notes. However, I can do it differently, not necessarily via Github releases.

Feel free to skip this ticket. Thanks for looking into it.

@terinjokes

This comment has been minimized.

terinjokes commented Jun 20, 2017

I, likewise, would love to have the ability to set the body. I have the body content on disk, but have no way to tell dpl to use it.

@abitrolly

This comment has been minimized.

abitrolly commented Jun 27, 2017

Travis allows to pass body to Octokit. The only problem is to figure out how to quote it for command line - see #657.

@valeriomazzeo

This comment has been minimized.

valeriomazzeo commented Jul 5, 2017

@abitrolly I am having exactly the same issue, did you find a solution?

For me this worked:

body: "Test Body"

but I can't manage to expand a variable containing a proper changelog

@abitrolly

This comment has been minimized.

abitrolly commented Jul 5, 2017

@valeriomazzeo no solution. But perhaps the problem is in properly escaping newlines in expanded var.

@valeriomazzeo

This comment has been minimized.

valeriomazzeo commented Jul 5, 2017

@abitrolly I made some progress with this and managed to get a successful upload:

before_deploy:
  - brew install jshon
  - export BODY=$(jshon -s "$(cat CHANGELOG.md)"))

deploy:
  provider: releases
  skip_cleanup: true
  api_key: ...
  body: ${BODY}

jhson properly escapes the markdown, I have tried setting that very same string in Octokit.rb and it gets uploaded properly and markdown show us correctly.

Although, when running from travis, markdown doesn't show up correctly, I am trying trimming the double quotes now:

export BODY=$(sed -e 's/^"//' -e 's/"$//' <<<$(jshon -s "$(cat CHANGELOG.md)"))

but if travis/dpl/releases doesn't add them properly when calling the client function, I am afraid it's not going to work.

@BanzaiMan

This comment has been minimized.

Member

BanzaiMan commented Jul 5, 2017

While @valeriomazzeo's case appears to show that simple spaces may not be much of a problem, as the value specified for body is passed through to dpl and Octokit, the spaces (including newlines) could be a problem.

Escaping the body value may be able to get around this, I am not entirely certain what that would look like (both on the dpl command line, as well as on .travis.yml).

Perhaps we can have a separate option that reads the body parameter from a different source (e.g., a file).

@valeriomazzeo

This comment has been minimized.

valeriomazzeo commented Jul 5, 2017

Trimming the double quotes works too, but the markdown doesn't show properly.

Using Octokit.rb directly, works as expected:

client.create_release("myuser/myrepo", "0.3.2", options = {:body => "# Change Log\n\n## [0.3.1](https:\/\/github.com\/myuser\/myrepo\/tree\/0.3.1) (2017-07-05)\n[Full Changelog](https:\/\/github.com\/myuser\/myrepo\/compare\/0.3.0...0.3.1)\n\n**Merged pull requests:**\n\n- Removed version log [\\#30](https:\/\/github.com\/myuser\/myrepo\/pull\/30) ([valeriomazzeo](https:\/\/github.com\/valeriomazzeo))\n- Fixed table names [\\#29](https:\/\/github.com\/myuser\/myrepo\/pull\/29)\n\n\n\n\\* *This Change Log was automatically generated by [github_changelog_generator](https:\/\/github.com\/skywinder\/Github-Changelog-Generator)*"})

Using travis:

screen shot 2017-07-05 at 19 03 24

If I edit the release, the markdown shows up escaped.

Note: screenshot and client command are not the same text

I am running out of ideas here...

is there a way to test dpl directly?

@valeriomazzeo

This comment has been minimized.

valeriomazzeo commented Jul 5, 2017

I wrote a simple script to simulate bash / ruby interaction:

require 'octokit'

def foo(options={})
  client = Octokit::Client.new(:access_token => "youtokenhere")

  user = client.user
  user.login

  #puts options

  client.create_release("myuser/myrepo", "0.3.2", options = { :body => options[:body] })

  # this works too:
  # client.create_release("myuser/myrepo", "0.3.2", options.merge({:draft => true}))

end

foo(:body => ARGV[0])

executing the following produces the correct result:

export BODY=$(cat CHANGELOG.md)
ruby test.rb "${BODY}"

Any other variant doesn't work as expected:

ruby test.rb "hello\n\nworld" shows -> Hello\n\nworld

export BODY=$(cat CHANGELOG.md)
ruby test.rb ${BODY}

shows only the characters up to the first space

I see that the value is not wrapped in quotes, but I don't see how my script is any different than dpl:

invalid option "--body=# Change Log\n\n## [0.3.2](https://github.com/myuser/myrepo/tree/0.3.2) (2017-07-05)\n[Full Changelog](https://github.com/myuser/myrepo/compare/0.3.1...0.3.2)\n\n\n\n\\* *This Change Log was automatically generated by [github_changelog_generator](https://github.com/skywinder/Github-Changelog-Generator)*"
failed to deploy
@BanzaiMan

This comment has been minimized.

Member

BanzaiMan commented Jul 5, 2017

@valeriomazzeo #155 (comment) the text shown indicates that \n was passed literally, rather than the newline which was intended. Could you try passing \\n instead? (Depending on the level of escaping, even more backslashes may be necessary.)

@valeriomazzeo

This comment has been minimized.

valeriomazzeo commented Jul 5, 2017

@BanzaiMan if you see my last comment:

invalid option "--body=# Change Log\n\n## [0.3.2](https://github.com/myuser/myrepo/tree/0.3.2) (2017-07-05)\n[Full Changelog](https://github.com/myuser/myrepo/compare/0.3.1...0.3.2)\n\n\n\n\\* *This Change Log was automatically generated by [github_changelog_generator](https://github.com/skywinder/Github-Changelog-Generator)*"
failed to deploy

Perhaps there is something wrong going on between travis.yml and ruby dpl?
"${BODY}" doesn't seem to get expanded?

Update:

so... the error message comes from here:

die("invalid option %p" % arg) unless match = OPTION_PATTERN.match(arg)

OPTION_PATTERN = /\A--([a-z][a-z_\-]*)(?:=(.+))?\z/
die("invalid option %p" % arg) unless match = OPTION_PATTERN.match(arg)

It turns out quotes are perfectly fine and it's all good, but we have been confused by the error message which is definitely a red herring.

The real problem is that regular expression that doesn't allow options to contains certain characters, in particular I believe the only problems are new lines.

@valeriomazzeo

This comment has been minimized.

valeriomazzeo commented Jul 5, 2017

@adamvoss

This comment has been minimized.

adamvoss commented Jul 25, 2017

I'm not sure this is a good option anymore.

This is supported since #189. However there is an issue with how it handles new-line characters (appear as '\n' rather than the literal new line.) and possibly markdown is escaped (have not verified).

Most of the time, we upload to a existing release which already has a body, so we can't set it.

I suppose you have more aggregate statistics than me, but none of my projects or those contributed configuration behave this way. Maybe I am doing things wrong?

I think that it would be really confusing for the user to have the body option that they specify not applied in some cases but occasionally in others.

Agreed, could the description be over-written? I expect so, so then by default don't over-write but add a config option that enables overwrite?

Secondly, you can easily edit the body yourself in the github ui.

If I accept this as true, then I can "easily" manually execute build scripts and upload releases to GitHub 😉 . I agree not all use-cases will lend themselves to specifying the body via Travis, but those that do probably have reasons and benefits for doing so. For example, the one I am working on now puts the filesize and sha265 hash in the release body which is information that is required by the ecosystem that will be utilizing the released files.

EDIT: Of course, disconcertingly, I seem to be finding the hash calculated by travis is different than the one when I download from GH Releases...

@astorije

This comment has been minimized.

astorije commented Feb 5, 2018

Hey there, I see a lot of discussion in here, but as @Midnighter commented in travis-ci/travis-ci#8568 (comment), I'm not sure if a solution was mentioned.

Essentially, what I'm trying to achieve is, whenever a tag gets built on Travis, extract the corresponding changelog entry from CHANGELOG.md, and create a GitHub release with that extracted Markdown content (for a practical example, see this changelog entry and this release, the release content is a copy-paste of the changelog entry).

In an ideal world, I would do something like the following, is this any possible?

before_deploy:
  - "export CHANGELOG_NAME=`cat CHANGELOG.md | ./extract_relevant_changelog_entry_name`"
  - "export CHANGELOG_BODY=`cat CHANGELOG.md | ./extract_relevant_changelog_entry_body`"

deploy:
  provider: releases
  skip_cleanup: true
  api_key: ...
  name: ${CHANGELOG_NAME}
  body: ${CHANGELOG_BODY}
  on:
    tags: true

Oh, question while I'm here: could you confirm that uploading a file is not necessary? I.e. in the example above, I really just need to set name/body, but not upload any file.

@Midnighter

This comment has been minimized.

Midnighter commented Feb 5, 2018

I tried a number of different ways but I think the solution @valeriomazzeo brought forward is the only workable one. No matter how you enter the content it always gets garbled by the deploy script.

remcohaszing added a commit to remcohaszing/pywakeonlan that referenced this issue Mar 25, 2018

Don’t add releases body using travis
This is not properly supported.
See travis-ci/dpl#155
@stale

This comment has been minimized.

stale bot commented May 6, 2018

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

@stale stale bot added the stale label May 6, 2018

@Midnighter

This comment has been minimized.

Midnighter commented May 7, 2018

Before this issue disappears from the face of the earth. Are there any plans to change the GitHub releases deployment or not?

@stale stale bot removed the stale label May 7, 2018

@benyanke

This comment has been minimized.

benyanke commented Jun 2, 2018

I would also love to see a solution here. I would like to make my release notes the commit message for the final release commit, which would be very easy to generate, along with a bit of boilerplate on the bottom....this is, of course, impossible right now.

christlang added a commit to synyx/urlaubsverwaltung that referenced this issue Jul 14, 2018

@christlang

This comment has been minimized.

christlang commented Jul 14, 2018

I would also love to see a solution here

christlang added a commit to synyx/urlaubsverwaltung that referenced this issue Jul 14, 2018

christlang added a commit to synyx/urlaubsverwaltung that referenced this issue Jul 14, 2018

christlang added a commit to synyx/urlaubsverwaltung that referenced this issue Jul 14, 2018

yoshuawuyts added a commit to yoshuawuyts/github-templates that referenced this issue Aug 22, 2018

@Jaskaranbir

This comment has been minimized.

Jaskaranbir commented Sep 7, 2018

If this helps anyone, here's a simple bash script I am using to create automated releases: https://gist.github.com/Jaskaranbir/d5b065173b3a6f164e47a542472168c1

It uses github-changelog-generator to generate changelogs (changelogs are written to CHANGELOG.md, which I then read, convert to JSON, and make a Github-API call). Of course, modify and use as required.

@micheljung

This comment has been minimized.

micheljung commented Oct 12, 2018

Please add this, sounds a like a low hanging fruit 🥝 :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment