Update airbyte-ci action to install dev if pipeline has been edited

[bnchrch]

Overview

1. Updates our airbyte-ci github action to download the dev version if piplines has been modified
2. Updates our airbyte-ci release action to always run on PRs that modify pipelines

closes #33418

Pain points

1. Github doesn't consitently give you the sha that triggered the event: 1, 2
2. The shorten sha action didnt account for this or let us override the sha it was shortening (so I removed it)
3. Waiting on a github workflow to complete depended on waiting on its check name (not filename) which felt brittle so I opted for polling instead.
4. These are github actions, the change and verify cycle is LONG, so lets focus on done not perfect with this one.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
airbyte-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 20, 2023 4:57pm

[alafanechere]

If I'm not mistaken the release will be triggered on airbyte-ci file changes only.
So if you make a change to a non airbyte-ci related file on a later commit the run-dagger-pipeline/action.yml will never resolve a binary for this commit.

I think that a dev install with pipx when the PR (not the commit) has airbyte-ci modified files is easier to implement.

Another option would be to always trigger this workflow (no paths filter) and use tj-actions/changed-files to only trigger a release if the branch has airbyte-ci modified files.

I'm not sure if tj-actions/changed-files returns the changed-files compared to the previous commit or compared to the target branch

[bnchrch]

If I'm not mistaken the release will be triggered on airbyte-ci file changes only.

So interestingly enough this was the case previously when using push.paths. However its not the case for pull_request.paths + pull_request.types=synchronize, which will fire everytime the branch is update and there is a change matching the path in anyone of the commits that make up the branch

I think that a dev install with pipx when the PR (not the commit) has airbyte-ci modified files is easier to implement.

I think your right. I went down this path as it would be useful to test pipeline changes using the final pyinstaller executable. As this is what the end users actually run.

But looking at this now, the steps we take to poll for new dev binaries that match your commit is brittle and more complex than we should tolerate.

TLDR: Ill update to use the pipx dev install instead

[bnchrch]

@alafanechere back up and ready for review. We no longer are using the dev executables but instead the pipx install. Much simpler.

[alafanechere]

Thanks! I confirm it works: I opened a PR based on this one on which I've modified pipeline code -> the formatting workflow installs airbyte-ci with pipx