search

karolsluszniak / ex_check

One task to efficiently run all code analysis & testing tools in an Elixir project. Born out of 💜 to Elixir and pragmatism.
https://hex.pm/packages/ex_check
MIT License
308 stars 11 forks source link

Improve Github Actions & get rid of TravisCI #30

Closed dolfinus closed 2 years ago

dolfinus commented 3 years ago

Hello.

It looks like you have both Github Actions and TravisCI integrations enabled. Unfortunately, TravisCI integration with open source projects is now ruined because of new billing plan which limits the resources available to CI jobs. A lot of projects (like ecto, absinthe and so on) there moved to Github Actions because it has no such restictions and also it is available for every user of Github. So I propose to get rid of the TravisCI integration completely.

Also I have some improvement of the CI pipeline you have.

Firstly, there is an annoying fact about Github Actions - sometimes it runs actions twice. For example:

  1. You just pushed a commit to a branch - testing workflow will run only once
  2. Someone forked your repo and creates a pull request - same thing
  3. You've created a new branch (feature, bugfix or release branch), pushed a commit here and also created a pull request to the main branch - two copies of workflow will be run

Running a workflow twice does not make any sense, it just takes twice the time without any useful side effect.

So in this PR I've also added a separated job of checking if another copy of workflow already started: https://github.com/fkirc/skip-duplicate-actions

This job allows to:

  1. Skip the second copy of workflow in the case 3 (branch in original repo + PR to main branch). Cases 1 and 2 will work just the same as now
  2. Skip workflow if someone changed only files which are not connected to package code, like README or CHANGELOG
  3. Cancel already started workflow in the same PR or branch if someone pushed new commits to it.

Secondly, I've found another quite annoying bug - step actions/cache does not update cache item if it was restored using a primary key. For example, some dependencies like dialyzer or other ones store their files in deps or _build folders (which are cached in the workflow). But when these dependencies perform some updates of these folders, it does not lead to the updating of mix.lock file. File hasn't been changed -> hash is the same -> cache primary key is the same -> caching action will not update the existing cache. This will cause the increase of workflow run time because the stored cache will not be used by some steps. Until mix.lock will be updated which will lead to updating the cache item. Here I've appended a commit SHA to the cache primary key, so it will always be updated. But it will not affect cache reading.

What do you think about that?

dolfinus commented 3 years ago

@karolsluszniak I've made few updates of this PR, could you please take a look?

dolfinus commented 3 years ago

Checked and fixed all the notes. This is an example how workflow has been executed on a forked repo: https://github.com/dolfinus/ex_check/actions/runs/726857793

dolfinus commented 3 years ago

I've fixed lines you've mentioned, here is a successful workflow run: https://github.com/dolfinus/ex_check/actions/runs/760671046

dolfinus commented 2 years ago

@karolsluszniak Any updates here?

karolsluszniak commented 2 years ago

@dolfinus Hey. Sorry for the delay. I wanted to merge and removed PLTs that were not needed as a final touch, triggering a build that came red from everything except Elixir 1.11... Looks like it needs another look.

dolfinus commented 2 years ago

Sorry, I'm not interested in this PR anymore. If you need these changes, you can pick them up to the master branch