Finish project setup about vavr-gwt HOT 13 CLOSED

It does work :-)

from vavr-gwt.

Build triggers: https://docs.travis-ci.com/user/triggering-builds

from vavr-gwt.

Hi @ruslansennov,

I fiddled around a bit with the project today and want to get rid of the parent pom of this project.

These are the options:

1. have two repos javaslang-gwt and javaslang-gwt-example
2. have one repo and one project with a maven profile for the gwt-example

I favor the first, because the example is started manually. And does not need necessarily have to depend on the actual development branch of javaslang-gwt.

What do you think?

I also checked docs on how to setup a travis-ci trigger. Need to perform tests (locally).

The solution will contain a script trigger-module.sh (in javaslang core repo) that is called with parameter javaslang-gwt. So it will scale to trigger any kind of javaslang module in future.

The only thing is that I need to figure out the travis-ci token. I once have generated it I think but I'm not sure... Maybe I need to re-generate it...

from vavr-gwt.

Hi

I favor the first, because the example is started manually. And does not need necessarily have to depend on the actual development branch of javaslang-gwt.

Let's keep this in one repo for a while, as is. Our main goal is to make CI and snapshot/release deployments

from vavr-gwt.

Ok, thank you!

I have problems with the travis access token within the Javaslang core project. The trigger-script works on my local machine - seems sth related to travis encrypt in conjunction with accessing environment variables on the CI server.

Will try to add an encrypted variable to the get project:

travis encrypt --org -r javaslang/javaslang-gwt 'TEST_KEY=TEST_VALUE'

And print that in an after_success step on the CI server to the console (just a test value):

after_success:
  - echo "TEST_KEY: $TEST_KEY"
  - echo "env.TEST_KEY: ${env.TEST_KEY}"
  - echo "env.global.TEST_KEY: ${env.global.TEST_KEY}"
  - echo "global.TEST_KEY: ${global.TEST_KEY}"

Update: Interestingly the javaslang-gwt project shows the following:

But the Javaslang core project does not...

The only difference between the travis configurations (that I spot) is, that the javaslang-gwt project does not use double-quotes:

env:
  global:
    secure: ADb+...4v4CHKgIjlc=

The Javaslang core project config does use double-quotes:

env:
  global:
    - secure: "HU0QOLEDk...NkM8l0="
    - secure: "VByzrX+iZ...ZN8hF4f5/V8="
    - secure: "GWvKpGPBF...1mVj4LI="

However, the output of the javaslang-gwt test-build was not successful:

from vavr-gwt.

Next try...

.travis.yml

after_success:
- ./test.sh

test.sh

#!/usr/bin/env bash

echo "TEST_KEY: $TEST_KEY"
echo "TEST_KEY: ${TEST_KEY}"
echo "env.TEST_KEY: ${env.TEST_KEY}"
echo "env.global.TEST_KEY: ${env.global.TEST_KEY}"
echo "global.TEST_KEY: ${global.TEST_KEY}"

Update: This test looks good:

from vavr-gwt.

Still does not work. Message: wrong_credentials, access denied.

See also travis-ci/travis.rb#340

from vavr-gwt.

Huston, we have a problem 👀

it seems that the travis-ci env variables are not set at all in the javaslang project. At least I can't read them. I wrote a similar build config and test-script in the javaslang-gwt project and there it works 🤔

In the above example TEST: TEST_VALUE should be printed but it is just TEST: because the env variable TEST_KEY seems to be not present.

from vavr-gwt.

maybe we should ask help from travis developers?

from vavr-gwt.

Yes, but before I will try sth later. Maybe we overwrite with .travis/ a default folder? Will check that... It is suspicious that the env vars aren't set at all.

from vavr-gwt.

Indeed, the javaslang core does not seem to have env vars on the build server. These are the resulting/parsed configs on travis-ci.org:

javaslang ("global_env": null)

javaslang-gwt ("global_env": "TEST_KEY=[secure]")

I will create further tests for setting up the env properly in the javaslang core project.

from vavr-gwt.

I've checked the last master branch build of javaslang core. The env vars are present. I think the vars are gone on PR builds for security reasons.

I will clean up the PR and merge - it should already work 😊

from vavr-gwt.

Yep, there it is. Now waiting for the triggered get build ...

from vavr-gwt.