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

Archives Ansible Project
1

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

2

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?

3

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

4

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.

5

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​

6

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

7

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.

8

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

9

Correct. Now it sounds like you can do:

http://stackoverflow.com/questions/5471174/git-move-branch-pointer-to-different-commit

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.

10

​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?

11

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? :slight_smile: