action #62693
closedqe-yam - coordination #56477: Implement notifications in case specific files were changed in PR
[tools] Implement github action to check if staging is affected and notify the user
0%
Description
So as per our research:
- "Encrypted environment variables are not available to pull requests from forks due to the security risk of exposing such information to unknown code." (https://docs.travis-ci.com/user/environment-variables/). So that we are not able to provide github token to make a comment as expected in the Pull request from oorlov;
- Internal Jenkins cannot be triggered by GitHub Webhook as it is not visible from the outside. Running cron job with some interval requires to check all the PRs every time and decide if the message should be put or not;
- External Jenkins requires node to be located on physical machine in DMZ;
- And finally, solution with posting a comment in PR requires special email to be created (in @suse.de or @suse.com domain) and GitHub account for the bot.
Solutions proposed below still would work, but much easier to simply use github actions now.
On top of that:
- all the mentioned above issues persist and jenkins on opensuse.org is an overkill
- we can easily host JS app with probot(https://probot.github.io/) on glitch platform (need to confirm if that's ok as we need to store tokens there)
- we can also just use rest-api from ci.suse.de and implement whole logic there to detect new/edited PRs
- original option of having github app running in azure is most prominent, will require more work to wrap everything in container to simplify maintenance, etc.
- we have an account for os-autoinst we can use to access rest-api (we have token)
- glitch.com requires to many permission to run app stored on github, this is no go, therefore probot doesn't have clear advantages over ruby octokit https://github.com/octokit/octokit.rb
- more of hacky solutions:
- require comment in special format for VR, otherwise fail travis
- use gitlab CI which will mirror all PR from github
- use https://github.com/probot/smee.io to proxy webhook calls (as per readme, it's not designed for production, so should not be used)
So the outcome is that we need github app + all infrastructure for it (we already have a VM in azure cloud)
See motivation in the parent ticket.
Acceptance criteria¶
- There is a message in PR for the contributor in case staging tests are modified (at least modules used in schedule and all schedules)
Updated by riafarov almost 5 years ago
- Subject changed from [functional][y] to [functional][y] Implement github app to check if staging is affected and notify the user
- Description updated (diff)
Updated by riafarov almost 5 years ago
- Priority changed from Normal to Low
As of now this is an overkill for the goal we have and as we have separate schedules, seems that it has mitigated the issue significantly. So we are waiting for other point we can include in such CI to justify existence and maintenance.
Updated by okurz over 4 years ago
Maybe all the new approaches that are taken with github actions can help to resolve some of the problems more easily, e.g. there might be an easier solution for the "secure credentials". But I must say I don't understand why you would want to post a comment when instead it could be conducted as a check or test within the CI pipeline?
Updated by riafarov over 4 years ago
okurz wrote:
Maybe all the new approaches that are taken with github actions can help to resolve some of the problems more easily, e.g. there might be an easier solution for the "secure credentials". But I must say I don't understand why you would want to post a comment when instead it could be conducted as a check or test within the CI pipeline?
The main thing here is that we cannot assure that changes being done to the modules work as we don't trigger full validation for staging tests. That means that we can only notify developer to consider running validation against staging. As for credentials, Santi made me aware that we already have some tokens which we could reuse for the github app.
From our experience we can see that moving staging schedule to yaml has resolved almost all issues, as I didn't see a single breakage since there, so modules modification wasn't main cause of failures there, that's another reason why it's on hold.
I will check if github actions helps resolving issue of accessing secure variables from forks, as otherwise we could simply use github api (which we tried originally).
Updated by riafarov over 4 years ago
So, after quick look, seems that github actions have same issues as travis running for the PRs from forked repos: https://github.community/t5/GitHub-Actions/Run-a-GitHub-action-on-pull-request-for-PR-opened-from-a-forked/td-p/15426
Updated by riafarov about 4 years ago
- Status changed from New to Rejected
- Assignee set to riafarov
We can use github actions now, so rejecting this one as is an overkill for now.
Updated by riafarov about 4 years ago
- Subject changed from [functional][y] Implement github app to check if staging is affected and notify the user to [functional][y] Implement github action to check if staging is affected and notify the user
- Description updated (diff)
- Status changed from Rejected to New
- Assignee deleted (
riafarov)
Hijacking to ue github actions instead.
Updated by okurz about 3 years ago
- Project changed from qe-yam to openQA Tests (public)
- Subject changed from [functional][y] Implement github action to check if staging is affected and notify the user to [tools] Implement github action to check if staging is affected and notify the user
- Category set to Enhancement to existing tests
- Status changed from New to Resolved
- Assignee set to okurz
IMHO solved with https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/13462 and the dedicated schedule files. With a schedule file having "staging" in the name it should be obvious what the effect is if you change that :)