Closed machour closed 4 years ago
Seems not to be a problem now.
@samdark IMO it is needed more than ever. With current fragmentation of packages it may be easy to break some package by minor BC break in used dependency (so change in package A may break package B).
What package should we test as integration one?
This is not about integration tests. This is about breaking package tests by some external changes. Every package should have tests run every X days to ensure that they're still working fine.
Where will we send notifications?
Travis supports the following options:
It seems to me that the best idea for group alerts in our case is Slack. Travis documentation has great example of separating alerts based on the build result. This allows you to receive notifications of successful builds in one channel, and notifications of failed builds in another:
notifications:
slack:
- rooms:
- <account>:<token>#failures
on_success: never
on_failure: always
template:
- "%{repository_slug} (%{commit}) : %{message}"
- "Build details: %{build_url}"
- rooms:
- <account>:<token>#successes
on_success: always
on_failure: never
template:
- "%{repository_slug} (%{commit}) : %{message}"
- "Build details: %{build_url}"
Yes, Slack should be fine.
@samdark can you add two new slack rooms for these purposes? We will invite everyone who is interested in receiving notifications to these rooms.
Added build-successes
and build-failures
.
@samdark now we need encrypted credentials for Slack integration, which we can use in public repositories. Set up a new Travis CI integration and encrypt the tokens of each room.
I need encrypted credentials for both rooms. Our public configuration will look something like this:
notifications:
slack:
- rooms:
- secure: "ABC5OwLpwB7L6Ca...."
on_success: never
on_failure: always
template:
- "%{repository_slug} (%{commit}) : %{message}"
- "Build details: %{build_url}"
- rooms:
- secure: "ABC5OwLpwB7L6Ca...."
on_success: always
on_failure: never
template:
- "%{repository_slug} (%{commit}) : %{message}"
- "Build details: %{build_url}"
You see here the encrypted string "ABC5OwLpwB7L6Ca....", which I need for adjusting travis configs in yii public repositories.
Your workspace has reached the integration limit
:(
Hmm...
Do we really need all these apps? How to understand which of this can be safely disabled? What is not used? Is it real to understand?
Oh. Wow. I have no idea why all these are enabled :) Thanks for pointing it.
Not sure I've got the tokens correctly but it should be so.
Great :)
Now... for a test we'll take two repositories β one with the last successful build and one with a failed one. 1) https://travis-ci.org/yiisoft/di 2) https://travis-ci.org/yiisoft/yii-captcha
In each I'll create a PR with a configuration of notifications. Next, we'll add Travis cronjobs for them and make sure that everything works as intended.
Do you need these merged?
Yes, merge both PRs to the master branch in both repositories.
Done.
Now open two pages: 1) https://travis-ci.com/yiisoft/di/settings 2) https://travis-ci.com/yiisoft/yii-captcha/settings
Find "Cron Jobs" section there.
Add the following schedule for both repositories:
Scheduled.
Hmm ... something strange happened. In Travis, the build history for these repositories has disappeared. 1) https://travis-ci.com/yiisoft/di/builds 2) https://travis-ci.com/yiisoft/yii-captcha/builds
I no longer see a single build on these pages :(
These are at .org (yes, messy): https://travis-ci.org/yiisoft/di/builds
I've set up there as well.
Damn, these Travis domains are some kind of hell :) Now we will wait for a builds on schedule.
I'm thinking more and more about CircleCI...
Two builds ended more than 20 minutes ago:
But there are no notifications in Slack... So something went wrong. I'll try to understand what the problem is.
I'm thinking more and more about CircleCI...
With the exception of domain confusion, Travis seems to work well :) There are no other objective reasons for changing it...
This is just marketing... We should look at what is really inconvenient for us now in Travis, and not what CircleCI promises in its comparisons :)
The issue with notifications is likely connected with the fact that encrypted tokens are tied to concrete repository (this one). Repository is specified during the generation process. It doesn't seems we can omit it (but there could be a way I haven't seen).
I just programmatically encrypted Slack token without using Travis CI client. Then created PR using this token: https://github.com/yiisoft/yii-captcha/pull/23
Build failed: https://travis-ci.org/yiisoft/yii-captcha/builds/598125538 Notification came to Slack:
Thus, the process of generating encrypted tokens for 80 repositories can be automated.
Is it still per-repository token?
Is it still per-repository token?
Yes. It is :) The token can only be generated using the name of the repository.
The process of setting schedules can also be automated: https://developer.travis-ci.org/resource/cron#create
It seems that itβs possible to write a small script that will do everything for us :)
I'll think a little more about it...
Guys, for clarity: Iβm going to first deal with task #27, and then implement a console command that can generate Travis cronjobs and encrypted Slack tokens for integration.
@samdark
yii-dev-tool
locally yii-dev-tool/config/travis/slack.local.php
(use slack.local.php.example
as example)master
branch)./yii-dev travis/update-slack-config --verbose
@rugabarbo done.
So now we have notifications. What's left if setting up cronjobs.
Thank you, @rugabarbo.
I have installed a cronjob for all repositories using command ./yii-dev travis/ensure-cronjob
(see PR #58).
I had to install both on travis-ci.COM and travis-ci.ORG, because itβs not possible to determine exactly which domain each repository is active on π Mess...
Everything seems to be in place now. Closing.
Thanks, @rugabarbo
@samdark reopen, please.
Builds of repositories, which are located only on domain travis-ci.COM, are launched by cron, but notifications do not come to Slack...
We need to think about why this is happening and fix it.
Arrgh. That's a mess with .com and .org :(
Keep calm :)
I have found a reason. For travis-ci.COM, we need to get the keys differently during Slack token encryption: https://docs.travis-ci.com/user/encryption-keys/#obtaining-the-public-keys
I'll fix it.
I can migrate everything to .com so it will be consistent. They finally have migration procedure available.
I can write a small console command for automatic migration. Travis API provides the ability to start migration: https://developer.travis-ci.com/resource/repository#migrate
How difficult is it to migrate everything manually? Is it possible to migrate everything with one click? If itβs difficult to migrate manually, it will only take me 10 minutes to write a command and start the migration using Travis API.
How difficult is it to migrate everything manually? Is it possible to migrate everything with one click?
Yes.
Migrated.
@samdark
yii-dev-tool
locally yii-dev-tool/config/travis/api.local.php
(use api.local.php.example
as example)master
branch)./yii-dev travis/update-slack-config --verbose
Pay attention, now in steps 3 and 4 you need tokens specifically for Travis API, not for Slack. Leave Slack token the same as it was!
All done but it seems there are problems:
https://notify.travis-ci.org/
I'll handle .org issue separately. Slack works well. Thank you again for preparing all that.
As briefly discussed on slack, it's becoming harder and harder to understand build failures in Yii 3 repos, as packages are inter-dependent and a tiny change in A can brake B without us noticing for days.
As a counter measure, could we setup Travis cronjobs as suggested by @rob006 on all repositories to run like every 2 days? (still unsure about the right periodicity)