Travis build stages have arrived. We should really start using these for snapcraft to avoid running things we know will fail.
We should additionally look into some integration with the travis integration snapcraft offers.
I am sort of using this as a TODO while on a weekend to not forget when the week starts ![:wink: :wink:](https://forum.snapcraft.io/images/emoji/twitter/wink.png?v=12)
@elopio what do you think?
1 Like
I think this is great.
Currently, our travis-ci integration would run many times if they have a matrix of tests, making duplicated pushes to the store. Before, it was necessary to add an env var to the matrix so the deploy was done only once.
With this, I think we can make it nicer. However, it’s still beta, so I would hold on that enable-ci change for a while.
What I want to do now is to make some parts of our nightly build sequential, to simplify the yaml.
I’m currently happy with the state of our PR executions, running everything in parallel, because even if there’s an error and the whole suite will have to run again after the fix, I don’t think it’s slowing down the PRs. What’s your opinion here @sergiusens, would you like to turn some parts of our PR runs into a sequential pipeline?
Ok, what do you think of this refactor?
https://github.com/snapcore/snapcraft/pull/1318
It’s using stages, but just a little. The big change is that we now get scripts that we can trigger to run the same thing that travis runs. The bulk of the work is now in the scripts instead of the .travis.yml.
will look in a bit. If possible though, make the cla check reporting more user friendly ![:slight_smile: :slight_smile:](https://forum.snapcraft.io/images/emoji/twitter/slight_smile.png?v=12)
That’s a separate branch
And as I told you, I’m hesitant to make CLA less verbose because travis recommends -ev. Let me also summon @ogra because he knows things.
The problem here is that our travis bash scripts are executed with -ev, so travis prints all the lines of the script as it executes them. This is useful when very bad things happen and I’m lost on why the script failed. But for successful executions, or things like the CLA check that fail in an expected way (when somebody has not signed it), the output is very confusing.
It does really ugly things, like when I put an echo, it will print:
echo "This is my step"
This is my step
![:unamused: :unamused:](https://forum.snapcraft.io/images/emoji/twitter/unamused.png?v=12)
Is there a better mode to run bash scripts? Or should I keep the -v but remove all the echos? Any other more clever solution?
I don’t mind the -ev if there is a nice summary of what went wrong at the end instead of having to read in between the lines from a sequential check.
Perhaps we should have the CLA check in Python? There’s the very nice pattern of only revealing the backtrace leading to an error when things fail.
That actually works for me ![:slight_smile: :slight_smile:](https://forum.snapcraft.io/images/emoji/twitter/slight_smile.png?v=12)
Having things in bash helps when we need to run them in the travis executor, but after this PR everything will run in docker.
1 Like