dmg for 3.3 release?

[brianbrownton]

On the releases page there is a dmg for 3.2 and for the continuous build, however there is no dmg for 3.3. Is this intentional or will there be a dmg released for 3.3?

[whoozle]

Unfortunately, I don't have any mac hardware to built it on. I'm not sure how to build it on travis now. Thanks for pointing this out, I'll take a look

[whoozle]

Don't know if it's relevant, but people are building 3.3 there themselves
macports/macports-ports#1743

[whoozle]

@d1vanov Hi, could you please advice how to add release builds for MacOSX using your script? I've been asked for for these numerous times really. It'd be great if it could be done your travis script automatically! :)

[d1vanov]

It is absolutely possible to do, I can try to look into the details later this week, however, I think I can already see the reason: it is the existing .travis.yml configuration:

branches:
  except:
    - # Do not build tags that we create when we upload to GitHub Releases
    - /^(?i:continuous)/

The comment pretty explicitly explains what happens here: "Do not build for any branches or tags except those which have "continuous" in their name". So when you create the release tag and push, no Travis build is triggered and hence neither macOS build nor Linux one is executed and hence there's nothing to automatically upload to the created release.

The fix should be simple: edit the branches configuration. There are many ways to do it, I myself use the following in my projects:

branches:
    only:
        - master
        - development

That means Travis CI builds are only triggered when you push stuff to master or development branches. It can be either a simple commit push or a tag creation, upload.sh script should figure out which build it is and upload to either the continuous release or the tagged one. With such branches configuration the build would also be triggered if someone makes a pull request to either of these branches - nothing is uploaded to either release in this case.

It seems you only have a master branch at the moment so in your case it the configuration can be simply

branches:
    only:
        - master

I can actually try this in my fork later this week to see how it goes. But if you have time, you can also try it yourself.

[whoozle]

No, I don't use additional branches, I don't have any. I only use feature branches for testing big sets of changes and then delete them, so current behaviour is pretty much fine to me. I don't want to support multiple release branches, hence the tags. :)

I just wanted to enable dmg/appimage builds for every release I tagged, I assume I have to fix except clause like that:

branches:
  except:
    - # Do not build tags that we create when we upload to GitHub Releases
    - /^(?i:continuous|v\d+\.\d+)/

Probably better to rewrite it using only: clause

[d1vanov]

Yep, that alternative should also work. You can also remove the comment above the regex since it would become misleading 😉

[d1vanov]

Sorry, I didn't find time the last week but I found some time for experiments today, here are the results:

• First, I must have messed something up but I wasn't able to trigger the build at Travis CI via the above discussed way. Here's what I did to trigger it:

branches:
  only:
    - master
    - /^v\d+\.\d+$/

So every push to master gets built and every release tag gets built.

• It seems upload.sh script wasn't really intended to be used for tagged releases. At least I wasn't able to get it to build tagged releases. For my experiment I replaced upload.sh with a tool I wrote which was originally inspired by upload.sh:

after_success:
  - |
    if [ "${TRAVIS_OS_NAME}" = "linux" ]; then
      find ./appdir -executable -type f -exec ldd {} \; | grep " => /usr" | cut -d " " -f 2-3 | sort | uniq &&
      wget https://github.com/d1vanov/ciuploadtool/releases/download/continuous-master/ciuploadtool_linux.zip &&
      unzip ciuploadtool_linux.zip &&
      chmod 755 ciuploadtool &&
      ./ciuploadtool -suffix="$TRAVIS_BRANCH" ./Android*.AppImage*
    elif [ "${TRAVIS_OS_NAME}" = "osx" ]; then
      wget https://github.com/d1vanov/ciuploadtool/releases/download/continuous-master/ciuploadtool_mac.zip &&
      unzip ciuploadtool_mac.zip &&
      chmod 755 ciuploadtool &&
      ./ciuploadtool -suffix="$TRAVIS_BRANCH" AndroidFileTransferForLinux.dmg
    fi

The results can be seen on the releases page of my fork - the latest release was created automatically via pushing a tag. The binaries are automatically built and attached to the release. The only postprocessing required is to edit the release information - add changelog etc.

@whoozle, if you like this result, I can prepare a pull request after cleaning up some mess left after my experiments. Or you can just take the above code snippets and put them to your .travis.yml yourself.

[whoozle]

No need for apologise! That's really great news! Thanks for your work.

Please create PR if you can, I can easily miss a thing. :)

[d1vanov]

Created #191. Seems to work well in my fork. The only unfortunate thing is that I couldn't figure out the way to make Travis CI rebuild tag 3.3 and reupload the binaries - that's because at tag 3.3's commit .travis.yml didn't contain the correct instructions how to upload the binaries... New releases from now on should be built and uploaded automatically, however, so if you don't mind it, you could just create a 3.4 release, you can even reuse the title from 3.3 - "No news is good news" 😃 I can imagine some alternative way with involving git rebase and git push --force but it's quite ugly, can't really recommend it.

[whoozle]

It's absolutely fine, I have a few more fixes, I'll just draft 3.4 shortly after

[whoozle]

@brianmorton Hi, Brian!
Thanks to effort of @d1vanov, it's all working now.

Please find new release at:
https://github.com/whoozle/android-file-transfer-linux/releases/tag/v3.4

[brianbrownton]

Thanks for your work everyone :)

[brianbrownton]

Homebrew/homebrew-cask#49242