Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[Suggestion] Different travis builds method at each PR

See original GitHub issue

Hey !

Since pull requesting any changes stats.exs run all the solutions for all the languages. I suggest to make these build independent from “already builded solutions” and only build new suggested solutions. Also make running all the solutions a possible option (when is modified for example).

My idea is to try to use as a data source for ProjectEuler repo since it is hosted 24/7 and we have control of it. If contains a list of solutions and configurations (as hidden frame, REST page or visible frame ( well presented for visitors too)), we can parse and make sure / stats.exs make the right job

  • Building and validate news problems

  • Building news solutions to already existing problems.

  • Build all solutions & problems ( actual default build )

  • A combination of the listed build ( sync / Async )

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:9 (9 by maintainers)

github_iconTop GitHub Comments

A-Hilalycommented, Nov 3, 2017

To validate the solutions the hashs is not enough? Well… an user can add too a wrong hash and this is hard to catch.

Exactly. That’s the “validation” thats worries me the most.

Of course it has drawbacks like we are supposing all previous tests are passing and only the current ones are error prone which could later stab us in the back maybe.

@lubien It is true that it can be dangerous to dare building only recent uploads/modifications. On the other hand, I totally agree that git differentials are necessary anyways to catch what was modified or added (even in my suggestion), the hosted service was more like to solve what @ryukinix said about wrong solutions (hashes). I think we all agree on using differentials now. Ill close this issue and create a new one after learning more about using git diffs.

lubiencommented, Nov 3, 2017

I vote to close this issue and start a new one on the subject of diff-based CI builds.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Trigger build on PR via API - Travis CI Community
The entire purpose of CI is to trigger automatically for every commit rather than manually. PRs are intentionally subject to stricter scrunity ...
Read more >
Travis builds the same commit twice (once in a branch and ...
Travis has always build the branch and PR, as they are essentially two different things, one being a development branch, and the other...
Read more >
Building Pull Requests - Travis CI Docs
Travis CI builds a pull request when it is first opened, and whenever commits are added to the pull request. Rather than build...
Read more >
Difference between $TRAVIS_EVENT_TYPE != 'pull_request ...
Based on the quoted Travis docs, in case of a push build, TRAVIS_PULL_REQUEST_SLUG is empty, in case of a PR build from a...
Read more >
Continuous Integration part 2: Setting up Travis checks in Github
Setting up TravisCI status checks on a PR is easy. ... is a piece of code you want to suggest to copy over...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found