Deployment to GitHub

skaller's Avatar


25 Oct, 2015 04:56 PM

Uploading artifact (94.4 MB)...OK
Skip "GitHub" deployment as environment variable has not matched ("appveyor_repo_tag" is "false", should be "true")
Build success

Huh? Where is that documented??

  1. Support Staff 1 Posted by Feodor Fitsner on 25 Oct, 2015 05:33 PM

    Feodor Fitsner's Avatar

    Standard environment variables are documented here:

  2. 2 Posted by skaller on 25 Oct, 2015 05:54 PM

    skaller's Avatar

    But the environment variable is wrong.
    It’s set to false, even though a tag was pushed.

    I suspect this is because I used

    git push —follow-tags

    which pushes ordinary commits AND tags at the same time.

    I just tried the “old way”, pushing just a single tag.
    We’ll see if that fixes it.

    I’m basically just following recipies.. I don’t really understand how everything
    fits together yet.

    For example in deploy section:

        appveyor_repo_tag: true # deploy on tag push only
    Somewhere else there’s a skip_tags: true field?
    To stop building when only a tag is pushed?
    So with this combo, deployment isn’t possible *unless*
    one stores an arifact in cloud storage, right?

    [But I can’t find that field, but then I’m trying to deploy
    from Travis as well so I can get confused easily :]

  3. 3 Posted by skaller on 25 Oct, 2015 06:13 PM

    skaller's Avatar

    Hmm .. here’s another problem. Rolling builds.

    As I understand it, when a build is queued or running and there
    is another commit, the queued or running job is cancelled
    and a new one queued. Is that right?

    In that case, if I commit a tag to trigger a deployment
    and then make another non-tag commit .. the deployment
    is lost. Right?

  4. Support Staff 4 Posted by Feodor Fitsner on 25 Oct, 2015 11:44 PM

    Feodor Fitsner's Avatar

    Right. What could be a solution here?

  5. 5 Posted by skaller on 26 Oct, 2015 12:19 AM

    skaller's Avatar

    Re rolling builds: there are a number I can think of.
    One is to schedule deployments separately from builds.
    Appveyor can do that, but it has cloud storage where you can put
    artifacts on a build, and then deploy them without building.

    It’s hard for me to tell because I don’t actually know what a
    deployment does because I haven’t been able to get one
    to work at all, either on Travis or Appveyor. The problem
    on Travis is below.

    I would also like to deploy from OSX. My primary dev machine
    is a Mac and I have a Windows box too (but no Linux anymore,
    I had to shut down my Rackspace slice due to cost). Deploying
    from home machines isn’t viable for me since I’m rather poor
    and I only have unreliable 3G wireless internet.

    In the case of OSX I don’t want to build every commit since I
    can build easily on my own box. On Linux I don’t want to build
    every commit either, because with my setup the only way I can
    move data from my Mac to my Windows box is via the internet,
    that is, using GitHub. Weird I know, they’re sitting next to each
    other but the data has to go across the Pacific and back to
    move less than one metre :)

    So basically I want a single point of control over edits, builds,
    and deployments via git.

    I’m also not the only developer (although I’m the main one).

    So one way is using tags, possibly matching regexps.
    Kind of messes up the repository though.

    Another would be to edit the YAML files each commit to
    tell the CI builders what to do. However doing that “by hand”
    is not really an option .. its not really continuous integration.
    I could write a control program. That would work, but its an extra
    thing to debug and get working and then get other developers
    to use ;(

    Sigh .. 30% or more of the last 15 years development has been
    writing and fighting with build systems, documentation systems
    and tools .. rather than actually designing my programming
    language, compiler, and library!

    Current issue:
    Deploying application

     <>/home/travis/.rvm/gems/ruby-1.9.3-p551/gems/octokit-4.1.1/lib/octokit/response/raise_error.rb:16:in `on_complete': POST 422 - Validation Failed (Octokit::UnprocessableEntity)

     <>Error summary:

     <> resource: Release

     <> code: missing_field

     <> field: tag_name

     <> resource: Release

     <> code: custom

     <> field: tag_name

     <> message: tag_name is not well-formed

     <> resource: Release

     <> code: custom

     <> message: Published releases must have a valid tag // See:

     <> from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/faraday-0.9.2/lib/faraday/response.rb:9:in `block in call'

  6. 6 Posted by skaller on 26 Oct, 2015 04:29 AM

    skaller's Avatar

    GitHub REPO: felix-lang/felix

    OK I finally have both Travis and Appveyor deploying to Github Releases.

    But there’s a really nasty problem. I think Appveyor is pushing a tag
    when it deploys. This triggers Travis again. Appveyor also ends up
    retriggered. So both CI servers are now in an infinite loop :)

    Appveyor is saying:

    Creating "felix-win64" release for repository "felix-lang/felix" tag "felix-win64" commit "7cd5483d34311d35ad7458588dbd9cf0f44e93d4"...OK
     <>Uploading "" to release assets...OK
    Build success

    i.e. you san see it actually pushes a tag. Travis is doing something too:

    Preparing deploy
    Logged in as John Skaller
    Deploying to repo: felix-lang/felix
    remote: Counting objects: 28658, done.
    Resolving deltas: 100% (22057/22057), completed with 164 local objects.
     * [new tag] felix-win64 -> felix-win64
     * [new tag] v1.1.6rc1 -> v1.1.6rc1
     * [new tag] v1.1.6rc2 -> v1.1.6rc2
    Current tag is: felix-win64

    Deploying application

    Done. Your build exited with 0.

    I removed the “deploy on tag” settings from Appveyor because it kept getting
    confused. I want to deploy from branch master, but if I push a tag, Appveyor
    thinks I created a branch. And it’s never master :)

    As I understand it, in git, *every* commit is a branch point. Tags are just
    names for commits. However a branch point isn’t a branch. A branch only
    exists if there TWO commits to a single branch point.

    In any case I am hoping to find a way to avoid the infinite loop.
    I am not sure exactly how to manage CI builds or deploys yet.

    A lot of my commits are done entirely to copy data from my edit Mac
    to my Windows box, 0.1 metre away, but connected only via GitHib.
    I don’t want builds on these commits. When doing generic work I probably
    want builds but not deploys. Pushing a tag of some kind to run a build
    and deploy seems reasonable.

    john skaller
    [email blocked]

  7. Support Staff 7 Posted by Feodor Fitsner on 26 Oct, 2015 04:37 AM

    Feodor Fitsner's Avatar

    When the tag is not set on GitHub provider settings it's set to release. This causes GitHub to create a new tag with release name and endless loop as a result.

    To fix that (if you deploy on tags only) add tag to GitHub deployment provider, so release is created for the existing tag:

    tag: $(appveyor_repo_tag_name)
  8. 8 Posted by skaller on 26 Oct, 2015 05:00 AM

    skaller's Avatar

    Hi, actually it doesn’t loop forever. What happens is that it retriggers once.
    Then i get this:
    The command "env PATH=bin:build/release/host/bin:$PATH LD_LIBRARY_PATH=build/release/host/lib/rtl FLX_MIN_MEM=0.01 make "FBUILD_PARAMS=--build-cc=/usr/bin/gcc-5 --build-cxx=/usr/bin/g++-5"" exited with 0.

     <>Skipping a deployment with the releases provider because this branch is not permitted

    Note that Travis is doing this:

    git clone —depth=50 —branch=felix-win64 felix-lang/felix

    Which IMHO is wrong. Why is it checking out a branch? There’s no branch.
    It’s just a tag on the master branch :)

    I have this YAML:

      skip_cleanup: true
      provider: releases
        secure: <..>
      file: felix-linux.tgz
        branch: master
        repo: felix-lang/felix

    I will now use:

      skip_cleanup: true
      provider: releases
        secure: <…>
      file: felix-linux.tgz
      tag: $(appveyor_repo_tag_name)
        tags: true
        repo: felix-lang/felix

    BTW: I found this which solves another problem:

    "If you don’t want to run a build for a particular commit, because all you are changing is the README for example, add [ci skip] to the git commit message.”

    At least for Travis. If I remember to put it in there :)

  9. 9 Posted by skaller on 27 Oct, 2015 07:32 AM

    skaller's Avatar

    I see you’re messing about with appveyor.yml in a clone of Felix.

    i invited you join as a member of the team.

    I didn’t realise you were doing that and have changed the YAML
    file myself (to use the tag name). Didn’t do what I expected :)

    BTW: what happens if I commit, then commit a tag?
    If we skip building on tags, ideally we’d build, post the artefact
    to the cloud store, then finish. Then run the deploy without the build.
    But stuff takes time and is queued.

    What happens if I use git push —follow-tags? Which commits code
    and tags together?

    I’m having “fun” with tags. I removed most of them from the GitHub origin,
    but forgot to remove them locally. So the next tag commit I did
    git push —tags and of course all the tags got posted back. Git’s tag
    management is not so hot. Unlike ordinary commits, where if you remove
    a file, committing removes it from the origin, tags doing seem to go away
    except from the repository clone you delete them from ;(

    [As you may guess i’m not a git expert .. or a windows expert either.]

    john skaller
    [email blocked]

  10. 10 Posted by skaller on 28 Oct, 2015 07:47 AM

    skaller's Avatar

    So .. if i make a change and commit it and then create a tag and push with —follow-tags

    * Travis builds and deploys, creating release
    * Appveyor says:

    Deploying using GitHub provider
     <>Creating "rc7v15.08.15" release for repository "felix-lang/felix" tag "rc7v15.08.15" commit "0ddc1494812423c99f52e5e33bcaa91c2a94745c"...Skipped (Release with tag "rc7v15.08.15" already exists)
     <>Uploading "" to release assets...OK
     <>Build success


    Because Travis was faster. It created the release.

    But Appveyor uploaded anyhow I think:

    Though its hard to tell because at the moment the artefact names are the
    same for every release. I need to fix that (it should be the Felix version

    So in summary: I have a workflow formula that should trigger a simultaneous release
    of both Linux and Windows binaries. Which is good. Thanks!!

    Of course it is not right, it doesn’t seem to be what either system documents.
    It’s not clear if I create a tag and THEN commit a change, so the tag
    refers to the repository PRIOR to the change, and then push, whether
    that will trigger a deploy or not.

    john skaller
    [email blocked]

  11. 11 Posted by support on 30 Oct, 2015 12:15 PM

    support's Avatar

    -- Please reply above this line --

    Hey John,

    Thank you for giving us those details :) I'm glad you were able to use
    GitHub releases!

    I believe the safest way to go would be pushing changes after tagging
    a commit :) that should trigger a build for sure.

    Regarding Travis CI being faster than Appveyor, I think releasing
    artifacts named differently depending on where you're triggering the
    build might be the way to go.

    Have a nice weekend, John!


    How would you rate my reply?
    Great [1]    Okay [2]    Not Good [3]

    María de Antón
    [email blocked]
    Visit for service status and uptime


  12. 12 Posted by skaller on 30 Oct, 2015 02:44 PM

    skaller's Avatar

    > On 30 Oct 2015, at 23:15, María de Antón <[email blocked]> wrote:
    > Hey John,
    > Thank you for giving us those details :) I'm glad you were able to use GitHub releases!
    > I believe the safest way to go would be pushing changes after tagging a commit :) that should trigger a build for sure.
    > Regarding Travis CI being faster than Appveyor, I think releasing artifacts named differently depending on where you’re triggering the build might be the way to go.

    Yes, the artifacts were always named “windows” or “linux”, but now the
    Felix version number is encoded in them as well.

    I’m using this to create a release:

    ./ $1
    git commit -a -m "New version `python3`"
    git tag `python3` -m "release `python3`"
    git push —follow-tags


    ~/felix>cat ./
    echo flx_version_major = '"'`date "+%Y"`'"' > buildsystem/
    echo flx_version_minor = '"'`date "+%m"`'"' >>buildsystem/
    echo flx_version_patch = '"'`date "+%d"`'"' >>buildsystem/
    echo flx_version_release = '"'$1'"' >>buildsystem/
    echo flx_version = flx_version_major+’"'.'"'+flx_version_minor+'"'.'"'+flx_version_patch+flx_version_release >>buildsystem/

    writes a Python module and

    import sys
    import version

    displays the version.

    Appveyor is triggered on commits AND tag adds or deletes.

    I’m not sure how binaries are added to GitHub Releases.
    If the tag is being modified with a link to the artiefact
    my Travis that might be triggering Appveyor a second time.

    Appveyor is running twice. It fails the second time to
    upload the file (its already uploaded it).

    Could that be happening?

    john skaller
    [email blocked]

  13. Support Staff 13 Posted by Feodor Fitsner on 30 Oct, 2015 06:44 PM

    Feodor Fitsner's Avatar

    Sorry, seems I'm not following the problem any more :-/ Could you please clarify what do you mean under "AppVeyor is running twice"?

  14. 14 Posted by skaller on 30 Oct, 2015 08:38 PM

    skaller's Avatar

    When I commit a change with a tag. both Travis and Appveyor do a build
    and deploy.

    Then Appveyor starts *another* build.

    A couple of those builds may be spurious because I manually deleted tags
    from GitHub and Appveyor is set to trigger on commits AND tag create/delete
    events. I added that setting as an experiment, perhaps I should remove it.

  15. 15 Posted by skaller on 30 Oct, 2015 08:41 PM

    skaller's Avatar

    > On 31 Oct 2015, at 05:44, Feodor Fitsner <[email blocked]> wrote:

    I meant to say in the last email that my theory is that Travis CI is somehow triggering
    the second Appveyor build. Since it finishes first it is creating the release. As I understand
    it, the release data is stored in the tag.

  16. 16 Posted by skaller on 30 Oct, 2015 09:19 PM

    skaller's Avatar

    I have a preliminary suggestion.

    At present if a commit message contains [ci skip] Appveyor will skip

    It would be useful if Travis did the same, then I would have a unified per
    commit way to skip building when I’m, say, changing documentation.

    It would also be useful if Appveyor recognised

    [appveyor skip]

    and Travis

    [travis skip]

    so if I am working on a platform dependent part of the code
    I can trigger one CI builder but not the other.

    Of course I can control builds by rewriting appveyor.yml and .travis.yml
    every commit (eg renaming them to something else will prevent building).
    But that’s a pretty heavyweight way to do a commit :)

    john skaller
    [email blocked]

  17. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 02:01 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac