QA (public) » openQA Project (public) » openQA Tests (public)

Shifting tickets after holiday period.

So recap from the last time we have attempted to do this thing:

• "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.

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
• 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)

I've created follow-up ticket with all the info. Checking if jdsn can propose any better solution than what we have figured out currently.