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

run CI with github actions #320

Merged
merged 27 commits into from
Jan 22, 2020
Merged

run CI with github actions #320

merged 27 commits into from
Jan 22, 2020

Conversation

wendevlin
Copy link
Contributor

@wendevlin wendevlin commented Dec 16, 2019

#319

My first try with github actions.

On every pull request and on pushed to master it runs the frontend and backend tests in parallel.

Closes #303

Copy link
Owner

@jelhan jelhan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for working on this one! Had the plan to change from TravisCI to GitHub Actions for quite some time. Travis isn't working that well for tests that require different languages. Guess you had some "fun" reading that .travis.yml.

I fear you missed some test cases. Guess due to the hard to read Travis configuration. Would be great if you could add them as well.

I'm a little bit confused that the GitHub Actions doesn't seem to run for this PR. Or are they just not reporting? Haven't worked that much yet with GitHub Actions to be honest. Do I have to activate something in repository config? Or do I just haven't looked at the correct places for CI reports?

.github/workflows/test-workflow.yml Outdated Show resolved Hide resolved
.github/workflows/test-workflow.yml Outdated Show resolved Hide resolved
@wendevlin
Copy link
Contributor Author

I'm a little bit confused that the GitHub Actions doesn't seem to run for this PR. Or are they just not reporting? Haven't worked that much yet with GitHub Actions to be honest. Do I have to activate something in repository config? Or do I just haven't looked at the correct places for CI reports?

Hey. Yeah me too. But it seems to need in master first. You can checkout my fork. There it was running.

@wendevlin
Copy link
Contributor Author

Hi @jelhan,

I did the changes now. But the browserstack tests failed :/
Maybe you can have a look: https://github.com/masterwendu/croodle/runs/352212277
I don't really get what the error says.

When you merge this PR you first have to add

  • BROWSERSTACK_USERNAME
  • BROWSERSTACK_ACCESS_KEY
    to the secrects of your github project. And you should change the password of your browserstack account. You should never have credentials within an opensource project in the source code!

It can be also possible with github actions to automatically do releases and bundle them. That could be an additional feature in the future

Copy link
Owner

@jelhan jelhan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I debugged the BrowserStack issue locally I think it's related to missing CI=true environment variable. That one controls part of the build. It's set by default on TravisCI. That might cause the difference. It's also important for other tests cause otherwise we test with a build that doesn't include all babel transforms required to support legacy browsers.

When you merge this PR you first have to add

* `BROWSERSTACK_USERNAME`

* `BROWSERSTACK_ACCESS_KEY`
  to the secrects of your github project. And you should change the password of your browserstack account. You should never have credentials within an opensource project in the source code!

If I remember correctly the credentials are included in code cause otherwise they are not available in build triggered by developers that aren't maintainers of the repo (read: pull requests by others). Are you sure that isn't an issue if using GitHub actions?

I would prefer to keep TravisCI for now and use both in parallel for some time. This would allow us to play around with GitHub Actions and keep TravisCI as a fallback if we face issues. Will remove later.

Can we run the tests for the frontend in parallel? Any chance to split up the jobs after installing dependencies? I've something in mind like the artifacts feature of GitLab CI. Install dependencies in first stage and then run the different tests using the installed dependencies from first stage. We could even split the tests for different browsers and run them in parallel on a shared build. This would result in a tree like this:

  • yarn install Install dependencies
    • yarn lint:js
    • yarn lint:hbs
    • yarn test:bundlesize (uses a production build)
    • yarn test:csp-header
    • yarn build --environment test Build for test environment, requires CI=true environment variable.
      • yarn test --launch Chrome --path dist
      • yarn test --launch Firefox --path dist
      • ember browserstack:connect
        • yarn test --launch BS_IE_11 --path dist --config-file testem.browserstack.js
        • yarn test --launch BS_MS_Edge --path dist --config-file testem.browserstack.js
        • yarn test --launch BS_Safari_Current --path dist --config-file testem.browserstack.js

If that's too much work for now or you aren't sure if that's even possible, we could also investigate that one separately.

.github/workflows/test-workflow.yml Outdated Show resolved Hide resolved
@jelhan
Copy link
Owner

jelhan commented Dec 17, 2019

I wasn't aware that in current setup all tests require a fully working PHP environment due to including api in build. It's not necessary if the build is only used for testing. Especially not if it's only for CI.

This small change disables the inclusion of API for test environment:

diff --git a/lib/include-api-in-build/index.js b/lib/include-api-in-build/index.js
index 5dd4b16..0662105 100644
--- a/lib/include-api-in-build/index.js
+++ b/lib/include-api-in-build/index.js
@@ -20,6 +20,13 @@ module.exports = {
   name: 'include-api-in-build',
 
   postBuild(result) {
+    let environment = this.app.env;
+
+    // do not include app if build is for testing purposes only
+    if (environment === 'test') {
+      return;
+    }
+
     let outputPath = result.directory + '/api';
 
     return Promise.resolve()

Hope that makes it easier for you.

Co-Authored-By: Jeldrik Hanschke <jelhan@users.noreply.github.com>
@jelhan
Copy link
Owner

jelhan commented Dec 20, 2019

If I read the docs of borales/actions-yarn right, it's kind of deprecated:

Please keep in mind that this Action was originally written for GitHub Actions beta (when Docker was the only way of doing things). Consider using actions/setup-node to work with Yarn. This repository will be mostly supporting the existing flows.

Using actions/setup-node should also work fine isn't it?

- uses: actions/setup-node@v1
  with:
    node-version: '10.x'
- run: yarn install
- run: yarn build --environment test
- run: yarn test --launch Firefox --path dist

If we are lucky this also fixes the issue of testem not finding chrome / firefox launchers. If not you might want to execute ./node_modules/.bin/testem launchers. The command should lists the recognized launchers.

@wendevlin
Copy link
Contributor Author

If I read the docs of borales/actions-yarn right, it's kind of deprecated:

Please keep in mind that this Action was originally written for GitHub Actions beta (when Docker was the only way of doing things). Consider using actions/setup-node to work with Yarn. This repository will be mostly supporting the existing flows.

Using actions/setup-node should also work fine isn't it?

- uses: actions/setup-node@v1
  with:
    node-version: '10.x'
- run: yarn install
- run: yarn build --environment test
- run: yarn test --launch Firefox --path dist

If we are lucky this also fixes the issue of testem not finding chrome / firefox launchers. If not you might want to execute ./node_modules/.bin/testem launchers. The command should lists the recognized launchers.

Hey, happy new year :)

Nice worked.
Now just the browserstack is missing.

@jelhan
Copy link
Owner

jelhan commented Jan 3, 2020

Happy new year!

Thanks a lot for keep working on this one. Guess you haven't expected it to be that much work, have you?

BrowserStack seems to be a tricky beast. Not sure but maybe it's caused by having the establishing of the tunnel and the test run in two separates commands? Did you tried to do it in one command?

      - name: Test in IE11
        run: yarn test:browserstack:connect && yarn test:browserstack-ie11 && yarn test:browserstack:disconnect

@wendevlin
Copy link
Contributor Author

Happy new year!

Thanks a lot for keep working on this one. Guess you haven't expected it to be that much work, have you?

BrowserStack seems to be a tricky beast. Not sure but maybe it's caused by having the establishing of the tunnel and the test run in two separates commands? Did you tried to do it in one command?

      - name: Test in IE11
        run: yarn test:browserstack:connect && yarn test:browserstack-ie11 && yarn test:browserstack:disconnect

No I haven't expected that! I just thought I am interested in github actions 😆

I think I give up. I have no insight on what is tested and where the issue could be.
Maybe you can fix it.

See the logs of the error here:

Run yarn test:browserstack:connect && yarn test:browserstack-ie11 && yarn test:browserstack:disconnect
yarn run v1.21.1
$ ember browserstack:connect
DEPRECATION: ember-i18n has been deprecated in favor of ember-intl
BrowserStack Tunnel Connected
Done in 6.36s.
yarn run v1.21.1
$ yarn test --launch BS_IE_11 --path dist --config-file testem.browserstack.js
$ ember test --launch BS_IE_11 --path dist --config-file testem.browserstack.js
DEPRECATION: ember-i18n has been deprecated in favor of ember-intl
not ok 1 BS_IE_11 - [undefined ms] - error
    ---
        message: >
            Error: Browser exited on request from test driver
            Non-zero exit code: null
            Stdout: 
             Closed BrowserStack Worker process SIGTERM
            
            
        browser log: |
            [object Object]
            [object Object]
    ...

1..1
# tests 1
# pass  0
# skip  0
# fail  1
Test suite execution has timed out (config.timeout = 1200 seconds). Terminated all test runners.


Stack Trace and Error Report: /tmp/error.dump.60a9f9b34fc02e33abf0707a94932324.log
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
##[error]Process completed with exit code 1.

@jelhan
Copy link
Owner

jelhan commented Jan 15, 2020

I think I give up.

I can totally understand! But let me propose another solution which might not be that disappointed. I think you have already finished > 95% of the work. Lets get that one in!

All tests are working except BrowserStack if I see it correctly. Maybe we just disable/remove that ones and still run them on TravisCI? We would be able to merge everything else and come back to that ones later.

If you don't have the time for it anymore, I can take over and do it myself. But I think it may be more satisfying to you to get your work merged directly.

Let me know which option you prefer.

@wendevlin
Copy link
Contributor Author

All tests are working except BrowserStack if I see it correctly. Maybe we just disable/remove that ones and still run them on TravisCI? We would be able to merge everything else and come back to that ones later.

ok yeah sure, good idea. I will try to do it within the next week

@wendevlin
Copy link
Contributor Author

@jelhan I removed the browserstack tests now and readded yaml tests.

@jelhan jelhan changed the title Add github actions run CI with github actions Jan 22, 2020
@jelhan jelhan merged commit 6043d23 into jelhan:master Jan 22, 2020
@jelhan
Copy link
Owner

jelhan commented Jan 22, 2020

@masterwendu Thanks a lot for working on this!

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

Successfully merging this pull request may close these issues.

Use GitHub Actions for CI instead of Travis
2 participants