GitHub Actions are no longer available for free to all github users

[ssbarnea]

With the official release of GitHub Action on Nov 14, two surprised appeared: GitHub prevented any organization that is on a paid plan to use them for free, something that was working fine during beta. It does not matter which repositories you want to use, you will not be able to use the free open-source plan if your entire organization was already paying for something.

This forced me to remove GitHub Actions from Ansible Molecule.

More details on https://github.community/t5/GitHub-Actions/GitHub-Actions-workflows-can-t-be-executed-on-this-repository/m-p/38208#M3260

I raised this problem to release-drafter because this is what I was using actions for (and am I quite happy that I did not bother to port CI from Travis).

What options are for people that are affected by this issue to use the release-drafter?

[jetersen]

Seems like a simple fix https://github.community/t5/GitHub-Actions/GitHub-Actions-workflows-can-t-be-executed-on-this-repository/m-p/38466/highlight/true#M3369

[ssbarnea]

Sadly no workaround if affected repo is under a non-free organization (even if your repo is open source). Anyone that is paying something to github will not be able to use these for free, also officially stated by GitHub staff on their forum and on tweeter.

Mainly GitHub confirms that is “be design” and not a bug.

[jetersen]

You can continue using the Release Drafter GitHub app?
https://github.com/apps/release-drafter

[ssbarnea]

I just requested it. I am not admin there but I pinged @gundalow about it, hopefully it will work.

And thanks for writing it, is very useful for (re)building release notes, not perfect but clearly helps us do less paperwork with PRs.

[gundalow]

Bot enabled in ansible/molecule

[JamesMGreene]

@ssbarnea @gundalow I left a comment on @ssbarnea's merged PR that remove Actions that you should check out.

TL;DR: The Ansible organization may qualify for a voucher that would grant you a free Teams plan.

[TimonVS]

Hey all, we're planning to deprecate the Release Drafter GitHub App. The GitHub App will continue working for the foreseeable future but it won't receive any further feature updates. Instead we want to focus on GitHub Actions. In doing so, it will mean that every organization that uses Release Drafter must be on a plan that supports GitHub Actions. So my question is: does the workaround that @JamesMGreene proposes work for you? Or do you see any other problems in us deprecating the GitHub App?

[ssbarnea]

@TimonVS I hope you reconsider your deprecation plans because GitHub Actions are an evil vendor locking (may sound paranoic, but read all). Due to the problems discovered in the last months I stopped adding workflows to any project and removed it from many.

Let me explain their implications:

• github does not allow any push that touches files under .git/workflows, that is mainly breaking "git" protocol and prevents users from using 3rd party project gating. I faced this myself on few projects, yep: it means that the only way to modify these files is to edit them in GUI and push them directly, bypassing your own jobs. It means that you will break linting jobs, unless you whitelist anything that is under the .github/workflows folder.
• costs and implications: mainly organization that has a paid plan can use actions for free, even of these projects are purely open-source, a detail GitHub silently missed to mention.

Maybe it would worth considering publishing a docker container that can be run by anyone. Probably you could use the same container in the github app itself.

[jetersen]

• github does not allow any push that touches files under .git/workflows, that is mainly breaking "git" protocol and prevents users from using 3rd party project gating. I faced this myself on few projects, yep: it means that the only way to modify these files is to edit them in GUI and push them directly, bypassing your own jobs. It means that you will break linting jobs, unless you whitelist anything that is under the .github/workflows folder.

What? I been pushing changes to .github/workflows files no issues, not sure what your on about.

• costs and implications: mainly organization that has a paid plan can use actions for free, even of these projects are purely open-source, a detail GitHub silently missed to mention.

@ssbarnea did you try and reach out to GitHub about the free teams plan? as suggested by @JamesMGreene

[TimonVS]

Thanks for your input @ssbarnea! I've been mulling it over and I think it makes sense to keep support for the GitHub App alive. We'll want to make the Actions version the primary way for people to use Release Drafter as it has certain benefits: access to the logs, no need to install an app that requires repo permissions and the ability to lock to a specific version. I can't make any promises yet though, I'll keep you posted.

As for the implications you mentioned, could you perhaps expand on your first point? Do you have a repo somewhere where I can see this happen?

[ssbarnea]

Here are few places where we recently removed workflows:
ansible/molecule#2443
ansible/ansible-lint#633
ansible-community/pytest-molecule#59
ansible-community/molecule-libvirt#6
ansible-community/molecule-digitalocean#2
ansible-community/molecule-azure#18

Mainly any repository that hosts something under this path is doomed not to be able to use an external merger, as they will fail to push the merge if one of these files is touched. Mainly GitHub managed to make it sure that they are the only one that can gate a project.

[jetersen]

what error do you get when trying to merge something into .github/workflows? I honestly have never experienced any issues.

[jetersen]

I had no issue modifying or deleting it locally and merging locally:
https://github.com/casz/test-workflow-delete/pull/1
https://github.com/casz/test-workflow-delete/pull/2

using the command line:

git checkout master
git merge --no-ff deleteMe
git push origin master

[ssbarnea]

I was corrected by @pabelanger about this: what github prevents is the use of merge button when a PR alters these magic areas. They respond with ['403 Resource not accessible by integration'] - this means that they are forcing the user to copy/paste changes in the editor to avoid using PRs.

Zuul CI documentation was updated with a notice regarding the issue https://zuul-ci.org/docs/zuul/reference/drivers/github.html#application

If I remember well push may be possible only via HTTP but not via SSH or something like this, I do not remember. Also be sure you do touch something inside that file path.

They did not fix the issue in 3 months, so I doubt is a priority. Still for those few that rely on CI/CD to perform the merges, this is a kind of a deal breaker.

[jetersen]

@ssbarnea my remote's are always ssh because of url insteadof: https://github.com/casz/dotfiles/blob/4dcf74a6888bd49936153b02a13db1dd238506bf/git/gitconfig#L50-L51

git remote -v
origin  git@github.com:casz/test-workflow-delete.git (fetch)
origin  git@github.com:casz/test-workflow-delete.git (push)

[jetersen]

Hmm, I would like to question how often would you change the .github/workflows files in an automated pull requests process? Once you have created your GitHub actions they are rarely changed.

Is it that much to ask for user interaction? This could be done because of security concerns. To prevent rogue CI modification that will start doing nefarious things (crypto mining).

[ssbarnea]

@Casz It is unlikely to need to change these but breaking the CI/CD ability to merge has nasty side effects. These systems assume that they have exclusivity on making changes. If the git repository gets changes by someone else (like github "gui" edit), they will get confused. That is not a bug in Zuul, is more of a gate security protection.... as in "there should be only one gate".

In fact for the same security reasons we configure the repositories to allow merger only from the Zuul-CI user.

How about travis, circle.ci,... files? Github didn't do anything about these and I am sure bots can take benefits of them too. They did not include any option to disable this "feature". If they back on that we should be good.

A common protection for malicious PRs is to not run CI jobs before a core adds a safe-to-test label to the PR. I know at least one project that does this: https://github.com/containers/libpod

Anyway, I can also relate with your point of view as using actions seems a much easier system to maintain than a service based app.

[jetersen]

If it was not clear, I am in favor of not deprecating the app. I only question some of the arguments used as to why it should not deprecate it.

[jetersen]

This is no longer true with the recent changes to the GitHub plans: https://github.com/pricing