Deployment to GitHub
Uploading artifact felix-win64.zip (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??
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | 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
Support Staff 1 Posted by Feodor Fitsner on 25 Oct, 2015 05:33 PM
Standard environment variables are documented here: http://www.appveyor.com/docs/environment-variables
2 Posted by skaller on 25 Oct, 2015 05:54 PM
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 Posted by skaller on 25 Oct, 2015 06:13 PM
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?
Support Staff 4 Posted by Feodor Fitsner on 25 Oct, 2015 11:44 PM
Right. What could be a solution here?
5 Posted by skaller on 26 Oct, 2015 12:19 AM
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 https://api.github.com/repos/felix-lang/felix/releases: 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: https://developer.github.com/v3/repos/releases/#create-a-release
<> 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 Posted by skaller on 26 Oct, 2015 04:29 AM
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
<https://ci.appveyor.com/project/skaller/felix/build/1.0.718#L6424>Uploading "felix-win64.zip" to release assets...OK
<https://ci.appveyor.com/project/skaller/felix/build/1.0.718#L6425>
Build success
i.e. you san see it actually pushes a tag. Travis is doing something too:
travis_fold:end:dpl.1
travis_fold:start:dpl.2
[33mPreparing deploy[0m
Logged in as John Skaller
Deploying to repo: felix-lang/felix
remote: Counting objects: 28658, done.[K
…….
Resolving deltas: 100% (22057/22057), completed with 164 local objects.
From https://github.com/felix-lang/felix
* [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
travis_fold:end:dpl.2
travis_fold:start:dpl.3
[33mDeploying application[0m
travis_fold:end:dpl.3
travis_time:end:30aa825c:start=1445831962705486415,finish=1445831974710701044,duration=12005214629
[0K
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]
http://felix-lang.org
Support Staff 7 Posted by Feodor Fitsner on 26 Oct, 2015 04:37 AM
When the
tagis not set on GitHub provider settings it's set torelease. 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:
8 Posted by skaller on 26 Oct, 2015 05:00 AM
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 https://github.com/felix-lang/felix.git 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:
deploy:
skip_cleanup: true
provider: releases
api_key:
secure: <..>
file: felix-linux.tgz
on:
branch: master
repo: felix-lang/felix
I will now use:
deploy:
skip_cleanup: true
provider: releases
api_key:
secure: <…>
file: felix-linux.tgz
tag: $(appveyor_repo_tag_name)
on:
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 Posted by skaller on 27 Oct, 2015 07:32 AM
I see you’re messing about with appveyor.yml in a clone of Felix.
Thanks!
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]
http://felix-lang.org
10 Posted by skaller on 28 Oct, 2015 07:47 AM
So .. if i make a change and commit it and then create a tag and push with —follow-tags
THEN
* Travis builds and deploys, creating release
* Appveyor says:
Deploying using GitHub provider
<https://ci.appveyor.com/project/skaller/felix/build/1.0.731#L6063>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)
<https://ci.appveyor.com/project/skaller/felix/build/1.0.731#L6064>Uploading "felix-win64.zip" to release assets...OK
<https://ci.appveyor.com/project/skaller/felix/build/1.0.731#L6065>Build success
Why?
Because Travis was faster. It created the release.
But Appveyor uploaded anyhow I think:
https://github.com/felix-lang/felix/releases
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
number).
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]
http://felix-lang.org
11 Posted by support on 30 Oct, 2015 12:15 PM
-- 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!
Best,
María
How would you rate my reply?
Great [1] Okay [2] Not Good [3]
--
María de Antón
[email blocked]
Visit https://www.traviscistatus.com/ for service status and uptime
details.
Links:
------
[1]
https://secure.helpscout.net/satisfaction/56832757/record/346313164/1/
[2]
https://secure.helpscout.net/satisfaction/56832757/record/346313164/2/
[3]
https://secure.helpscout.net/satisfaction/56832757/record/346313164/3/
12 Posted by skaller on 30 Oct, 2015 02:44 PM
> 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:
~/felix>cat release.sh
./newversion.sh $1
git commit -a -m "New version `python3 showversion.py`"
git tag `python3 showversion.py` -m "release `python3 showversion.py`"
git push —follow-tags
where:
~/felix>cat ./newversion.sh
echo flx_version_major = '"'`date "+%Y"`'"' > buildsystem/version.py
echo flx_version_minor = '"'`date "+%m"`'"' >>buildsystem/version.py
echo flx_version_patch = '"'`date "+%d"`'"' >>buildsystem/version.py
echo flx_version_release = '"'$1'"' >>buildsystem/version.py
echo flx_version = flx_version_major+’"'.'"'+flx_version_minor+'"'.'"'+flx_version_patch+flx_version_release >>buildsystem/version.py
writes a Python module and
~/felix>cat showversion.py
import sys
sys.path=['buildsystem']
import version
print(version.flx_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]
http://felix-lang.org
Support Staff 13 Posted by Feodor Fitsner on 30 Oct, 2015 06:44 PM
Sorry, seems I'm not following the problem any more :-/ Could you please clarify what do you mean under "AppVeyor is running twice"?
14 Posted by skaller on 30 Oct, 2015 08:38 PM
When I commit a change with a tag. both Travis and Appveyor do a build
and deploy.
Then Appveyor starts *another* build.
https://ci.appveyor.com/project/skaller/felix/history
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 Posted by skaller on 30 Oct, 2015 08:41 PM
> 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 Posted by skaller on 30 Oct, 2015 09:19 PM
I have a preliminary suggestion.
At present if a commit message contains [ci skip] Appveyor will skip
building.
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]
http://felix-lang.org
Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 02:01 AM.