tag mismatch in build

MikeG's Avatar


01 Jan, 2019 04:29 PM

For reference: https://ci.appveyor.com/project/m6z/sandbox/builds/21313264

It starts off using 1.0.54, but then bumps it to 1.0.55 (problem?):

Build started
git clone -q -n --branch=1.0.54 https://github.com/m6z/sandbox.git /home/appveyor/projects/sandbox
git checkout -qf 1.0.54
Running "before_build" scripts

At the end there is some kind of discrepancy between tag .54 and .55 which prevents the artifact from making it to GitHub releases (problem):

appveyor PushArtifact $mg_artifact_name
Uploading artifact cdd-v1.0.55.zip (3282 bytes)...100%
Deploying artifacts using GitHub provider
Creating "1.0.54" release for repository "m6z/sandbox" tag "1.0.54" commit "ca64bee20345c43b8dfe9f98205dca2376dfc8b5"...Skipped - release with tag "1.0.54" already exists
No artifacts were published. Make sure you have specified correct artifacts filter.
Build completed

Any advice?

  1. Support Staff 1 Posted by Ilya Finkelshte... on 01 Jan, 2019 08:39 PM

    Ilya Finkelshteyn's Avatar

    Hi Mike,

    APPVEYOR_BUILD_VERSION is unrelated to the tag. It is described here and it does not change depending on tag.

    If you need to access tag name from the build, you can use APPVEYOR_REPO_TAG_NAME environment variable.

    Artifact packaging section does not work because it happens before deployment (which includes before_deploy script). At the moment AppVeyor tries to package artifact, that file is not even created.

    Packaging from command line works because file already exist at this point.

    However when you package from command line, you do not provide artifact deployment name (cdd_artifact), but you refer artifact using that name in GitHub deployment settings, and because of this GitHub deployment cannot find an artifact. Please change appveyor PushArtifact $mg_artifact_name to appveyor PushArtifact $mg_artifact_name -DeploymentName cdd_artifact. And you can remove artifact packaging section if you package artifact from the script.

    Finally I would recommend to set $(APPVEYOR_REPO_TAG_NAME) in Tag field in GitHub deployment settings.

    Hope this makes sense. Feel free to ask any additional questions.


  2. 2 Posted by MikeG on 04 Jan, 2019 03:38 AM

    MikeG's Avatar

    Thanks for the reply! Maybe getting a little further. The build artifact appears to be created correctly, but then it does not make it to GitHub:

    Deploying artifacts using GitHub provider
    Creating "1.0.68" release for repository "m6z/sandbox" tag "1.0.68" commit "d61c3b39c131ac116cf85345f6bbe28d278c81d4"...
    Skipped - release with tag "1.0.68" already exists


    Any thoughts?

  3. Support Staff 3 Posted by Owen McDonnell on 04 Jan, 2019 04:53 PM

    Owen McDonnell's Avatar

    Did you try Ilya's recommendation of adding the tag field to GitHub deployment settings?

    The other setting that is relevant here is force_update: which is set to false by default but you should set to true in this case.

  4. 4 Posted by MikeG on 05 Jan, 2019 04:17 PM

    MikeG's Avatar

    Hmm, still baffling. Feel like every permutation of config setting has been tried and still no luck.

    Regarding the comment "$(APPVEYOR_REPO_TAG_NAME) should be in the Tag field". Is that in the settings web page of the project or the deploy: tag: field of appveyor.yml? In any case, both places have been tried with no success.

    Have also tried force_update:true and force_update:false.

    Still stuck on this result:

    Skipped - release with tag "1.0.80" already exists
    No artifacts were published. Make sure you have specified correct artifacts filter.
    Updating "1.0.80" release for repository "m6z/sandbox" tag "1.0.80"
    commit "5dce7e434aef7d3a1718d938fbbd74dd45077948"...

    Appreciate all the help!

  5. Support Staff 5 Posted by Owen McDonnell on 05 Jan, 2019 07:49 PM

    Owen McDonnell's Avatar

    Hey Mike,
    Sorry for the confusion, I think the problem is on our end. You can follow the issue here.

    As a workaround, can you try putting your packaging scripts at the end of the build_script: section.

  6. 6 Posted by MikeG on 09 Jan, 2019 03:47 AM

    MikeG's Avatar

    Yes, that works. Thanks very much!

  7. Owen McDonnell closed this discussion on 09 Jan, 2019 05:07 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

Recent Discussions

17 Jul, 2019 12:16 AM
17 Jul, 2019 12:15 AM
16 Jul, 2019 10:50 PM
16 Jul, 2019 07:47 PM
16 Jul, 2019 06:34 PM


16 Jul, 2019 05:17 PM
16 Jul, 2019 10:17 AM
16 Jul, 2019 07:46 AM
15 Jul, 2019 06:33 PM
15 Jul, 2019 06:09 PM
15 Jul, 2019 05:53 PM