Closed ericniebler closed 9 years ago
https://travis-ci.org/ericniebler/meta#L580
Maybe you have your password encrypted wrong?
I don't think it's yours. I deleted the branch with the pull request. I don't know why that pull request generated a second travis build, but I doubt that's your bug.
What is a mystery to me is why the bii publish -r
command seeminly succeeded, but my code on biicode is still pointing to the prior git commit.
Also, how do I keep my code on biicode from being updated when someone makes a pull request. Obviously, I don't want just any old code getting published.
Only block owners and collaborators have publish rights. Don't worry. In this case, you are the only one allowed to publish to ericniebler/meta
block. Also, in the case of PR and travis-based deployment the BIICODE_PASSWORD
is not decrypted in the fork nor the PR since travis generates encryption keys based on the repo.
However an user might create a block track, i.e. a fork, from ericniebler/meta
, but that's unrelated to your block exactly as a fork is unrelated to your repo.
_Check your encrypted password again, I'm not sure it's correct. Note bii user $BIICODE_USER -p $BIICODE_PASSWORD
command fails in your builds. You are actually not publishing anything, that's why the block is still pointing to the old commit_
Oh, so I should add back the guard around bii publish
, right? Also, how come the code on biicode
is missing the files that begin with a '.'
?
I'm guessing the problem is that in your docs here, you show the environment variable as "BII_PASSWORD
", but it's actually "BIICODE_PASSOWRD
", isn't it?
Let me see.. Ah, the global ignore.bii
file located at ~/.biicode/ignore.bii
ignores dotfiles by default. It's hierarchical like .gitignore
, you can override settings with !
if you like.
Ah, the global ignore.bii file located at ~/.biicode/ignore.bii ignores dotfiles by default.
That's kind of broken, isn't it?
It's whatever you want, these are bash variables only. So you followed the docs BII_PASSWORD
example and I wrote BIICODE_PASSWORD
in my example... My fault, sorry :(
Ah, the global ignore.bii file located at ~/.biicode/ignore.bii ignores dotfiles by default.
That's kind of broken, isn't it?
Ask the rest of the bees, @drodri for example ^^. This is users POV vs bii devs POV. Feel free to criticize.
That's kind of broken, isn't it?
That's kind of broken, isn't it?
Hi Eric, Diego from biicode here,
Not sure about it, why? I would say that the default expected biicode behavior is NOT to publish to biicode all ".git", ".idea" and similar files/folders. If you want to restore or publish, you can negate it. Adding to a ignore.bii:
!.gitignore
Will include and publish the .gitignore to biicode. Same can be done on folders or patterns. As Manu said, probably could be improved, any suggestion?
That's OK, I guess. It would be nice if it used the .gitignore file if there is one. If I want git to ignore a file, I probably want bii to, also. EDIT: or does it only publish the things that are in git?
Use .gitignore If available, I like that.
Probably we went too far with the ignore all starting with ".", and we could just explicitely add to global ignore.bii explicitely ".git", ".Thumbs.db" and the like. Using the gitignore if existing is a good idea, just submitted to our issues.
I would say there is a typo in BIICODE_PASSWORD in the declaration. Nevermind, just fixed. But we have clearly a bug in $ bii publish. You might try without the "-r" option. I am investigating.
Mmm so bii bug then, right? bii publish -r still raises an exception, and now Eric's password is ok....
You mean the "list index out of range" exception? That seems like a bug in biicode to me.
That's @drodri fault :) We apologise, maybe it's a matter of coding at late hours like today (2 AM here :P). Again, thanks for all your feedback Eric, and for giving biicode a try
You mean the "list index out of range" exception? That seems like a bug in biicode to me.
Yes a bug, totally our fault, sorry. Just spotted the origin, the "-r" option has not been updated to account for the new simple layout (bii init with "-l" option) I am working right now on it, will be fixed next release (next week). In any case the bii publish with "-r" at the moment is just for reference and linking to the repo, not really much used in the logic by now, so you might be fine without it for these days. Thanks!
Thanks for all the help yesterday, guys. Just a few more questions. Given the travis.yml, will the code code be published on biicode only when I push to master, or to any branch? And will bii be using @Manu343726's Meta block to resolve dependencies, or mine? How does it figure that?
Given the travis.yml, will the code code be published on biicode only when I push to master, or to any branch?
If you have that .travis.yml
in all branches it will push to biicode whenever you push since the build is being run. You can however do selective bii publish
depending on the branch the build is running from, check Travis docs: http://docs.travis-ci.com/user/ci-environment/#Environment-variables
And will bii be using @Manu343726's Meta block to resolve dependencies, or mine? How does it figure that?
In biicode there are two ways to ask for a dependency:
#include
to the requested file, like #include <ericniebler/meta/meta.hpp>
. Note on full paths the first two parts are always the user/block
of a block.#include <meta/meta.hpp>
, then you map that include to the block you want. For example, that's what I did on range-v3: #include <meta/meta.hpp>
plus an entry in biicode.conf
's [includes]
mapping any include of the form meta/*
to manu343726/meta
block. Note the [requirements]
entry above, setting the specific version of meta block requested, is needed.Thanks.
You can also find an example here in the docs: http://docs.biicode.com/c++/integration/ci.html#travis-ci where the existence of a git tag is used to decide to publish a STABLE version with biicode version_tag matching the git tag or just publish a DEV version.
I'm asking the bees about the
bii publish -r
exception. It's an odd bug, but I'm not sure its ours or the Travis VM going crazy, I noticed the failed builds you have with git fetching issues.