Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Travis CI is failing *not due* to PR issues #871

Closed
tubaman opened this issue Nov 15, 2019 · 5 comments
Closed

Travis CI is failing *not due* to PR issues #871

tubaman opened this issue Nov 15, 2019 · 5 comments

Comments

@tubaman
Copy link

tubaman commented Nov 15, 2019

Travis CI is failing even on a trivial PR: #870

To Reproduce

  1. Create a trivial PR
  2. See Travis CI fail

Expected behavior
Travis CI should only fail if there are issues with a PR

@ssbarnea
Copy link
Member

ssbarnea commented Nov 16, 2019

That is true but someone needs to address this, and I am currently not using the library.

By addressing it, I do not mean to disable CI testing, I mean finding a way to make it work. Atlassian test instance is working.

Hint: either make a PR that fixes the issue or use the ❤️ button at top of page and trying to persuade someone to make it work.

@tubaman
Copy link
Author

tubaman commented Nov 18, 2019

What's the Atlassian test instance?

@Addono
Copy link
Collaborator

Addono commented Nov 21, 2019

Been looking a bit into this today, the problem is that "Encrypted environmental variables" are used, which are not exposed on PR branches, as you will see when you inspect the build logs for a PR:

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions

And indeed, comparing the exposed variables in a PR:
image

Versus one by the maintainer:
image

Solution wise, Travis' documentation states this:

If your build relies on encrypted variables to run, for instance to run Selenium tests with BrowserStack or Sauce Labs, your build needs to take this into account. You won’t be able to run these tests for pull requests from external contributors.

To work around this, restrict these tests only to situations where the environment variables are available, or disable them for pull requests entirely, as shown in the following example:
...

Some solutions which come to mind:

  • Spin up a JIRA test instance as part of the CI/CD, then use that for testing, and afterwards tear it down. I am currently doing something like that in a Jenkins pipeline, which works fine, although it does take a minute or so for JIRA server to boot. But given that the current Travis pipeline already takes a couple of minutes this shouldn't be too much of an issue.
  • Make the CI user credentials public. Given that the Jira instance is solely used for testing is there not much damage one can do with these accounts (e.g. delete projects), although that would only be an option if it can be configured such that it has enough rights to pass the tests, but not enough to escalate its rights. For which I do not know if this is feasible.
  • Let people configure Travis for their own forks and deem that sufficient. Upside: Easiest (just add documentation). Downside: The PR itself will not pass, just the pipeline on the commits in the fork.

@Addono
Copy link
Collaborator

Addono commented Nov 21, 2019

What's the Atlassian test instance?

https://pycontribs.atlassian.net/

@ssbarnea
Copy link
Member

See #896

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants