Draft: Add Travis CI support

[prabhav-thali]

This refers to issue-19688. Adds Travis CI support to build multi-arch images.

Workflows migrated from GA to Travis CI:

• PR check
• Code Coverage
• Docker build on push to main branch
• Unit tests
• Release

In case of release workflow, we can trigger a manual build by using the trigger build option from Travis UI. After selecting branch, we can provide a custom config to override the config variables in .travis.yml.
For eg:-

env: 
  global:
  - TAG=<version-to-be-released>
  - RECREATE_TAGS=true
  - NO_COMMIT=true

Env variables to be set in Travis CI settings:
DOCKER_PASSWORD
DOCKER_USERNAME
GITHUB_TOKEN
MATTERMOST_WEBHOOK_URL
QUAY_PASSWORD
QUAY_USERNAME

Signed-off-by: Prabhav Thali [email protected]

[prabhav-thali]

cc
@nickboldt

[nickboldt]

Notes from today's call w/ Florent and other Che devs:

• Travis limits us to 3 jobs in parallel (3 arches = 3 jobs); with GHA, our limit is 20 jobs in parallel
• Eric and possibly others agree that doing PR checks on multiple arches is vital, so that's a lot of potential parallel builds (more than 3)
• we might want to enable PR checks for x to be required and z/p to be optional, so as to not block merging commits
• Travis is not currently enabled for the eclipse-che org in GH (only for eclipse) - need to get that enabled before these PRs can be validated. For that we need to open a BZ to talk to Denis R (Eclipse WM) to approve
• But once it's approved, only need to pass tokens between travis and GHA to be able to trigger GHA->T or T->GHA

@cwsolee can you talk to your people at Travis to ask if we can get more capacity than 3 parallel jobs? If that's a hard limit, then we can't use travis for more than Z builds and it makes sense to keep everything else in the 20-build GHA pool (x, arm, power, etc.), and have a GH action delegate to Travis for only the s390x arch builds.

[cwsolee]

Travis change our concurrency limit too, it's 20 now and Travis were quite willing to increase more when needed. With both time limit & concurrency limit increase, we haven't hit any problem since then.

[prabhav-thali]

Following changes are implemented:

• TRAVIS_TAG is added such that each pushed tag is suffixed with "-travis". And tag for image on each arch will be in the format 7.x.x-travis-${arch}

• To handle the build failures that may occur only on non-amd64 arch, Added allow_failures and fast_finish=true labels in case of PR check.

• In release workflow, removed execution of make-release.sh as it will conflict with GHA release. As tag is not pushed through Travis build, removed "check existing tag" step.

• Removed 2 workflows i.e. "code coverage : Test coverage report" and "license validation".

• Removed mattermost notification steps from Travis.yml.

• Added Travis API call in GHA workflows.

• Have added job for next build. Is nightly build job required to be added in Travis?

PR check limitation on triggering PR-check jobs on Travis via API:

• The Travis API token will be available to PRs raised by users with write access to that particular repo.

• Changes made to .travis.yml file in PRs will not be validated in PR check Travis jobs until the changes are committed into the repo.

While checking on the implementation, we found that the Travis request API doesn't support triggering builds on PR references.
(Ref: travis-ci/travis-ci#9907, https://travis-ci.community/t/trigger-build-on-pr-via-api/825)

However, as a workaround added below specified commands in the install section of PR-check jobs in travis.yml. However, If a PR contains changes in the travis.yml file, those won't be validated.

git fetch origin +refs/pull/${PR_NUMBER}/merge
git checkout -qf FETCH_HEAD

[cwsolee]

@nickboldt & @ericwill , We keep this PR as draft for u to take a look before we submit, let us know whether you've any comments. Comments from others are welcome too.

[nickboldt]

Have added job for next build. Is nightly build job required to be added in Travis?

No, we're moving from :nightly to :next, and will be removing all :nightly tags this week. See eclipse-che/che#19291

For the secrets/env vars, looks like we have two options:

a) UI - https://travis-ci.com/github/eclipse-che/che-machine-exec/settings
b) CLI - https://docs.travis-ci.com/user/encryption-keys/ (embed secrets in .travis.yaml using Travis gem)

Using option b, here's an updated PR based on this one: #170

[prabhav-thali]

Hi @nickboldt, As changes from this PR are taken forward in PR #170. Good to close this PR?

[nickboldt]

if everything you need is in #170, then yes.

[prabhav-thali]

@nickboldt I have updated the PR with changes from #170.

[nickboldt]

Running https://app.travis-ci.com/github/eclipse-che/che-machine-exec/builds/235860533 because of this merge.
Also expect to see a PR check from https://github.com/eclipse-che/che-machine-exec/pull/185/files but nothing so far, as PRs and branch pushes were disabled.

Now spinning in https://app.travis-ci.com/github/eclipse-che/che-machine-exec/builds/235860766/config

[nickboldt]

https://app.travis-ci.com/github/eclipse-che/che-machine-exec/builds/235860766 (PR check, build #9) is green.

The commit in https://app.travis-ci.com/github/eclipse-che/che-machine-exec/builds/235860533 (build #8) -- was stuck on the s390x steps, but has also passed. \o/

[nickboldt]

enabled travis for :next builds:

#186

Running in https://app.travis-ci.com/github/eclipse-che/che-machine-exec/builds/235862504 - ran for 6 mins, with 5 mins of waiting = total 11 mins.

MEANWHILE GH action is still going >20 mins.

[nickboldt]

[nickboldt]

GH action is complete now too -- took 17 mins longer (28 mins) than the Travis build (11 mins) for 3/4 of the same arches.

That's only one data point but it suggests that moving next, PR, and release build actions to Travis will certainly not make things slower :D

[benoitf]

on https://github.com/eclipse-che/che-machine-exec/runs/3382034579?check_suite_focus=true I see 'wrong credentials'

Run body="{
{
  "@type": "error",
  "error_type": "wrong_credentials",
  "error_message": "access denied"
}