Any chance for a 'stable' Ansible branch in main GitHub repository?

109 views
Skip to first unread message

dry...@gmail.com

unread,
Oct 2, 2014, 9:27:25 AM10/2/14
to ansible...@googlegroups.com
Hello,

I'm testing my Ansible roles (58 at the moment) on Travis-CI using RoleSpec
framework (https://github.com/nickjj/rolespec/). Testing is currently done
by cloning Ansible from its main GitHub repository and enabling "hacking
environment", which takes about 5 seconds.

During development I tend to use Ansible 'devel' branch to get the latest
features that are implemented in the project, and also to be two steps ahead
of possible bugs in Ansible code, which my project is very dependent upon.
Having a heads up on possible bugs and easy way to find them (by using
git bisect) and help fix them is very useful.

Recent changes in Ansible code have hindered me somewhat in that regard. For
example, currently 'ansible-galaxy' is broken on "devel" branch:

#v+
$ ansible-galaxy -p roles install debops.secret
- downloading role 'secret', owned by debops
- downloading role from https://github.com/debops/ansible-secret/archive/.tar.gz
- error: failed to download the file.
- debops.secret was NOT installed successfully.
- you can use --ignore-errors to skip failed roles.
#v-

Or, for some reason, "npm" is an invalid parameter:

#v+
$ debops applications -l helios
Running Ansible playbook from:
/home/drybjed/.local/share/debops/debops-playbooks/playbooks/applications.yml ...
ERROR: npm is not a legal parameter in an Ansible task or handler
#v-

Solving these issues on my workstation to for example bypass them for the time
being is simple - I just switch to current stable branch, v1.7.2, for a while
and check back the next day.

But the same cannot be said about automated tests (for example on Travis), and
I don't mean that it can't be done. I can still tell the build script to
switch to current stable Ansible version, v1.7.2, and it will work fine.

The problem I have is lack of a "stable" branch in Ansible git repository.
When next stable Ansible is released, I will need to modify build scripts to
point to current stable Ansible release, v1.8.0. And the same for next stable
release, and so on, and so on.

I think that having a "stable" branch in main Ansible git repository which
would be placed at current stable release (v1.7.2) and moved to next stable
release when it arrives, would benefit greatly many use cases where cloning
Ansible from git repository from a stable version is more useful than setting
up APT PPA, namely for role and module tests. With "stable" branch it would be
easy to create two-phase tests, first one on stable branch and second one on
devel branch. And the upkeep of those tests on new Ansible stable releases
would be minimized.

Are there any plans to create "stable" branch in Ansible git repository,
alongside current "devel" branch?

Maciej

James Cammarata

unread,
Oct 2, 2014, 10:41:35 AM10/2/14
to ansible...@googlegroups.com, dry...@gmail.com
Hi Maciej,

That error is interesting, as we had fixed that on Tuesday of this week - if you're still seeing that can you verify you're using the latest commit from devel?



--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/20141002132709.GA29627%40helios.gumed.edu.pl.
For more options, visit https://groups.google.com/d/optout.

dry...@gmail.com

unread,
Oct 2, 2014, 11:02:13 AM10/2/14
to ansible...@googlegroups.com
On Oct 02 09:41, James Cammarata wrote:
> That error is interesting, as we had fixed that on Tuesday of this week -
> if you're still seeing that can you verify you're using the latest commit
> from devel?

Sure. Just did a clean recursive clone of current devel (commit
43eb821d3f6564fad6bac78cd420d7ddd1f65a3c) and previous errors are still here:

#v+
$ debops applications -l helios
Running Ansible playbook from:
/home/drybjed/.local/share/debops/debops-playbooks/playbooks/applications.yml ...
ERROR: npm is not a legal parameter in an Ansible task or handler

$ ansible-galaxy -p roles install debops.secret
- downloading role 'secret', owned by debops
- downloading role from https://github.com/debops/ansible-secret/archive/.tar.gz
- error: failed to download the file.
- debops.secret was NOT installed successfully.
- you can use --ignore-errors to skip failed roles.
#v-

maciej

Michael DeHaan

unread,
Oct 2, 2014, 4:54:37 PM10/2/14
to ansible...@googlegroups.com, dry...@gmail.com
Ansible will not be keeping a seperate branch named "stable"

We use the development branch for development (ha), and then branch of each release, which are each "stable".

We also tag each release.

It might be useful for you to find the last tag that starts with "v", and checkout at that tag.





maciej

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

Serge van Ginderachter

unread,
Oct 2, 2014, 4:58:38 PM10/2/14
to ansible...@googlegroups.com, dry...@gmail.com
On 2 October 2014 22:54, Michael DeHaan <mic...@ansible.com> wrote:
Ansible will not be keeping a seperate branch named "stable"

​Why?
 
We use the development branch for development (ha), and then branch of each release, which are each "stable".
We also tag each release.

​TBH, I always found that counterintuitive, to have both a branch and a tag pointing to a minor branch.
 
It might be useful for you to find the last tag that starts with "v", and checkout at that tag.

​That's an ugly hack.​
 


​  Serge​



Brian Coca

unread,
Oct 2, 2014, 4:59:22 PM10/2/14
to ansible...@googlegroups.com

FYI, I've been using ansible daily with current devel checkout for 2+ yrs, its only broken 4 times (once by me) as they don't instamerge requests and even then was normally fixed within the hour.

Brian Coca

Michael DeHaan

unread,
Oct 2, 2014, 5:02:41 PM10/2/14
to ansible...@googlegroups.com, dry...@gmail.com
On Thu, Oct 2, 2014 at 4:58 PM, Serge van Ginderachter <se...@vanginderachter.be> wrote:

On 2 October 2014 22:54, Michael DeHaan <mic...@ansible.com> wrote:
Ansible will not be keeping a seperate branch named "stable"

​Why?
 
We use the development branch for development (ha), and then branch of each release, which are each "stable".
We also tag each release.

​TBH, I always found that counterintuitive, to have both a branch and a tag pointing to a minor branch.


Tags are specifically interesting milestone events.

If there are going to be other tags, the versions ought to be tags.

 
 
It might be useful for you to find the last tag that starts with "v", and checkout at that tag.

​That's an ugly hack.​
 


It solves his problem without any change in process, so I think it's nice that we were able to offer something.


dry...@gmail.com

unread,
Oct 2, 2014, 5:04:49 PM10/2/14
to ansible...@googlegroups.com
On Oct 02 16:54, Michael DeHaan wrote:
> Ansible will not be keeping a seperate branch named "stable"
>
> We use the development branch for development (ha), and then branch of each
> release, which are each "stable".

Of course "stable" name is just a suggestion on my part. For example, GitLab
flow suggests "production" for a branch with similar concept.

> It might be useful for you to find the last tag that starts with "v", and
> checkout at that tag.

OK, so that would essentially be:

git checkout $(git tag -l | grep "^v" | sort -nr | head -n 1)

versus:

git checkout stable

Not counting the submodule updates.

Maciej

Michael DeHaan

unread,
Oct 2, 2014, 5:08:00 PM10/2/14
to ansible...@googlegroups.com, dry...@gmail.com
Correct.  Now it sounds like you can do:


Though that seems a little squirley, and a maybe (though I'm being a bit paranoid) a bit dangerous.

I also don't really want to encourage submitting bugfixes to stable, we always cherry pick from devel.

So I think forcing the cognitive selection of what version you are running - and deciding when you wish to upgrade - may be  wise.







Maciej

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

Serge van Ginderachter

unread,
Oct 2, 2014, 5:10:21 PM10/2/14
to ansible...@googlegroups.com, dry...@gmail.com
On 2 October 2014 23:02, Michael DeHaan <mic...@ansible.com> wrote:
Tags are specifically interesting milestone events.

​Exactly. And tags often are that within a major branch,
Looking at the history, it makes sense to have e.g. a 1.7 branch, but not separate branches for the minor releases.​
Once you have a 1.7.2, you wont work on 1.7.1 any more.

Pardon my ignorance, but I still don't see nor got an answer on what the problem with a 'stable' branch would be?



Michael DeHaan

unread,
Oct 2, 2014, 5:14:33 PM10/2/14
to ansible...@googlegroups.com, dry...@gmail.com
You never know.   We're going to keep them around and they aren't hurting anything.

"Pardon my ignorance, but I still don't see nor got an answer on what the problem with a 'stable' branch would be?"

Because there are easy workarounds and it's not important?  :)




--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages