Dpl: Problems with GitHub deploy updating Release body

[PhilMFischer]

There seems to be an issue with updating the Release body message.

We have the following case:

Our build under https://travis-ci.com/github/virtualsatellite/VirtualSatellite4-DEV-IDE/builds/175412233 is running an integration build. It is setting the integration_snapshot tag always to the latest commit on the integration branch. Once the build is succesful some files are uplaoded to the integration Release https://github.com/virtualsatellite/VirtualSatellite4-DEV-IDE/releases . The body of the release message should be updated with the time and commit sha of the build.

This used to work fine and stopped meanwhile. Today it seems the release message is not getting changed at all when deploying.

[PhilMFischer]

Additional Info. Judging from our build history, It seems that the feature was working at least until 14. January 2020

[Velenir]

Have the same issue
Body stopped being filled somewhere between Jan 7 and Jan 27

Tried out using release_notes instead of body, to no avail.
On the other hand, file gets posted to releases without problem

[anxolin]

Same here! body stopped working without us doing any changes in the travis script

[BanzaiMan]

Sorry for the delayed response.

I've tracked this down to the introduction of configuration validator.

While we work on the fix, one workaround is to disable it in https://travis-ci.org/OWNER/REPO/settings, in the "Beta features" section at the bottom of the page.

We'll update this issue when the validator is fixed.

[Velenir]

Disabling build config validation doesn't help

[BanzaiMan]

Disabling build config validation doesn't help

Hmm. My test build https://travis-ci.org/github/BanzaiMan/travis_production_test/builds/719646560 resulted in this release https://github.com/BanzaiMan/travis_production_test/releases/tag/foo-2, based on this configuration:

https://github.com/BanzaiMan/travis_production_test/blob/3cadaed9e375bae7148bed3ebb8b70db8ada28db/.travis.yml#L12-L19

deploy:
  provider: releases
  api_key: $GITHUB_TOKEN
  file: readdir.c
  body: completely irrelevant text for the release
  skip_cleanup: true
  on:
    tags: true

Could you point to your problematic build?

[Velenir]

Could you point to your problematic build?

All the recent v1.3.0-test.* builds

[BanzaiMan]

@Velenir

Your configuration for v1.3.0-test.22 looks like this:

  - provider: releases
    api_key: $GITHUB_RELEASE_TAG_API_TOKEN
    release_notes_file: RELEASE_NOTES.md
    file: 
      - web_$TRAVIS_TAG.zip
      - ipfs_hash.txt
    skip_cleanup: true
    on:
      tags: true

This does not have body, which is what we are discussing here.

If you are looking to define the release text through release_notes_file, you need to use v2. (I do realize, now, that the individual Releases v2 provider documentation does not state this explicitly, and how you might come up with a configuration this way.)

At any rate, for you, adding edge: true should solve the problem.

[Velenir]

v1.3.0-test.20 uses release_note which should be the same as body as far as I understand

I'll try with edge, thank you

[BanzaiMan]

v1.3.0-test.20 uses release_note which should be the same as body as far as I understand

dpl v1 does not understand release_notes.

[Velenir]

I didn't know specifics about v2 :disappointed: . edge worked great

Than you very much! :tada:

[BanzaiMan]

@Velenir Happy to hear that it works for you now. I apologize for the confusion about the v2; I'll work on improving the docs.

[BanzaiMan]

Documentation issue (with v2) is addressed by https://github.com/travis-ci/docs-travis-ci-com/pull/2867

[BanzaiMan]

Workarounds, so far

1. Stay with v1, disable configuration validation in https://travis-ci.org/OWNER/REPO/settings
2. Move to v2 with edge: true. This should work whether or not configuration validation is enabled.

[stale[bot]]

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