## What
<!--
* Describe what the change is solving. Link all GitHub issues related to
this change.
-->
In some cases (recent release or progressive rollout), there were no
syncs with the most recent version of the connector. We still want to be
able to run regression tests.
## How
<!--
* Describe how code changes achieve the solution.
-->
We will allow this by adding an optional input in the GitHub action.
Other solutions that were discarded:
* Find the version released before the one active in prod. This is not
easily possible as we use [the cloud
registry](https://storage.googleapis.com/prod-airbyte-cloud-connector-metadata-service/registries/v0/cloud_registry.json)
in order to be able to know the version and there is only the most
recent version
* Try to get the previous version based on the version there was an
attempt on. For example, if the version is 2.1.1, we would check for
2.1.0. There are a couple of problems with this:
* if the patch version is 0, we don't know what is the patch version
from the previous version
* this assume that the previous released was active a bit and generated
syncs
Note that the above are not mutually exclusive so we could have the
second option work with the solution in this PR so maybe this is another
way to alleviate the problem in the future.
You can see the parameter beings passed
[here](https://github.com/airbytehq/airbyte/actions/runs/18538584966/job/52840046885)
when added to the GitHub action and is not passed when not added
[here](https://github.com/airbytehq/airbyte/actions/runs/18540377411/job/52846048671)
## Review guide
<!--
1. `x.py`
2. `y.py`
-->
## User Impact
<!--
* What is the end result perceived by the user?
* If there are negative side effects, please list them.
-->
## Can this PR be safely reverted and rolled back?
<!--
* If unsure, leave it blank.
-->
- [x] YES 💚
- [ ] NO ❌
## What
<!--
* Describe what the change is solving. Link all GitHub issues related to
this change.
-->
## How
<!--
* Describe how code changes achieve the solution.
-->
## Review guide
<!--
1. `x.py`
2. `y.py`
-->
## User Impact
<!--
* What is the end result perceived by the user?
* If there are negative side effects, please list them.
-->
## Can this PR be safely reverted and rolled back?
<!--
* If unsure, leave it blank.
-->
- [ ] YES 💚
- [ ] NO ❌
## What
Fixes bot-authored PRs being incorrectly labeled as "community"
contributions. This was happening because the GitHub Actions workflows
were referencing an outdated `@production` tag in the workflow-actions
repository that didn't include recent bot account exclusions.
**Link to Devin run**:
https://app.devin.ai/sessions/8501e183a3e14fee9491d4322b04a69f
Requested by: ian.alton@airbyte.io
## How
Updates both labeling workflows (`label-prs-by-context.yml` and
`label-github-issues-by-context.yml`) to reference a specific commit SHA
(`2a848ff`) in the workflow-actions repository instead of the
`@production` tag.
This commit includes the updated bot account exclusion list that
prevents the following accounts from being labeled as community:
- `devin-ai-integration`
- `octavia-bot-hoard`
- `octavia-bot-admin`
- `octavia-bot`
- `airbyteio`
- `github-actions[bot]`
- `dependabot`
- `speakeasybot`
- `airbyte-slash-dispatch-bot`
The `@production` tag was pointing to an older commit that only excluded
`octavia-squidington-iii` and `dependabot[bot]`.
## Review guide
1. `.github/workflows/label-prs-by-context.yml` - Verify the commit SHA
`2a848ffce5eaf8da66d4176b66f55dd2e1007016` is correct
2. `.github/workflows/label-github-issues-by-context.yml` - Same commit
SHA update for consistency
3. **Important**: Verify the commit exists at
2a848ffce5
4. Consider whether pinning to a specific commit vs using a versioned
tag (e.g., `v1.0.0`) would be preferable for future maintainability
## User Impact
**Positive:**
- Bot-authored PRs will no longer be incorrectly labeled as "community"
contributions
- More accurate contribution attribution in the repository
**Negative:**
- None expected. This only adds more bot exclusions; it doesn't change
behavior for human contributors.
**Note:** This change cannot be easily tested before merge since it
requires actual PR/issue events to trigger the workflows.
## Can this PR be safely reverted and rolled back?
- [x] YES 💚
Revert by changing the commit SHA back to `@production` or any other
valid reference in the workflow-actions repository.
Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Co-authored-by: ian.alton@airbyte.io <ian.alton@airbyte.io>
## What
We have a workflow that once a day checks if the latest CDK version
would break any connector. If there are test failures, it sends a slack
alert. In addition to sending a slack alert, we would like to get an
oncall ticket in our github project. We should only do this for
destinations (connectors owned by move)
## How
Added a few extra steps to the workflow that calls a script that creates
gh issues. It checks if an issue already exists for the connector. If it
does it will update the description with information about the new
failure. If it doesn't it will create a new ticket
## How did I test this?
Tested in this PR https://github.com/airbytehq/airbyte/pull/67617.
Confirmed that tickets were created if they didn't exist and that they
were updated if they did exist.
## Can this PR be safely reverted and rolled back?
<!--
* If unsure, leave it blank.
-->
- [x] YES 💚
- [ ] NO ❌
## What
The existing `CDK Connector Compatibility Test` workflow currently tests
all connectors using the bulk CDK. However, we only want to test
certified connectors. This PR modifies the workflow to run tests
exclusively on certified connectors using the CDK.
## How
Instead of getting the list of connectors to test from the diff
generated by running a CDK upgrade task, we will get the list of
certified connectors by reusing the script used in the auto bump
workflow to get this information.
## How did I test this?
Tested it in [this](https://github.com/airbytehq/airbyte/pull/67605) PR.
More specifically, here's the PR check run
https://github.com/airbytehq/airbyte/actions/runs/18410594109/job/52461620803?pr=67605
Note: it looks like the connectors we are testing didn't change. I'd
guess it is possible that in the future we will have some none certified
connectors using the cdk so the change in this PR still makes sense.
## Can this PR be safely reverted and rolled back?
<!--
* If unsure, leave it blank.
-->
- [x] YES 💚
- [ ] NO ❌
## What
Consolidates the Vale linting job from PR #65973 into the existing
Reviewdog workflow. This adds Vale as a second documentation linting job
alongside MarkdownLint, both using the same reviewdog reporter for
consistency.
Related to #65973
## How
**Workflow Changes** (`.github/workflows/reviewdog.yml`):
- Updated workflow comments to reflect that both MarkdownLint and Vale
run on docs
- Added a new `vale` job that runs after the `markdownlint` job
- Configured Vale to use `github-pr-review` reporter (matching
MarkdownLint's configuration)
- Uses `filter_mode: added` to only lint newly added content
- Uses `fail_on_error: false` to keep Vale checks non-blocking
**Vale Configuration Changes** (`docusaurus/vale.ini`):
- Changed `MinAlertLevel` from `suggestion` to `warning`
- This scopes Vale to only report warnings and errors, excluding
suggestions
## Review guide
1. **`.github/workflows/reviewdog.yml`** - Review the Vale job
configuration:
- Verify the `errata-ai/vale-action` parameters are correct
- Confirm `github-pr-review` is the appropriate reporter (changed from
`github-pr-check` in the original PR #65973)
- Check that `filter_mode: added` and `fail_on_error: false` are the
desired settings
2. **`docusaurus/vale.ini`** - Review the MinAlertLevel change:
- Confirm `MinAlertLevel = warning` is the desired behavior (excludes
suggestions, only shows warnings and errors)
- Note: The `airbyte.punctuation = NO` rule was already removed in
master, so no changes needed there
## User Impact
**Positive:**
- Documentation PRs will now receive automated Vale linting feedback
alongside MarkdownLint
- Both linters use the same reporter type for consistent PR annotations
- Vale will only flag warnings and errors, reducing noise from
suggestions
**Neutral:**
- This supersedes the separate Vale workflow from PR #65973, which can
be closed once this is merged
- No impact to existing MarkdownLint checks
## Can this PR be safely reverted and rolled back?
- [x] YES 💚
This only adds a new linting job to the Reviewdog workflow. Reverting
would simply remove the Vale checks without affecting the existing
MarkdownLint job or any other workflows.
---
**Session Details:**
- Requested by: Ian Alton (ian.alton@airbyte.io)
- Link to Devin run:
https://app.devin.ai/sessions/7993d1cba2464b48bbababe88bda0671
---------
Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Co-authored-by: ian.alton@airbyte.io <ian.alton@airbyte.io>
* reorganize to separate between jvm/python connectors
* add `bump-bulk-cdk-version`
* also - remove some old slash commands, which have been deprecated in
favor of the new stuff
## What
Updates the display names of non-privileged CI check titles in the
connector CI workflow to include "Non-Blocking" and provide actionable
guidance via slash commands.
When contributors submit PRs from forks, certain test steps run in an
unprivileged mode without access to secrets. This change makes it
clearer in the GitHub UI that these checks are non-blocking and provides
users with the `/run-connector-tests` slash command they can use to
trigger the full privileged tests.
**Requested by:** @aaronsteers
**Slack thread:**
https://airbytehq-team.slack.com/archives/C08PWJ16LUC/p1759864974450959
## How
Modified the test step names in
`.github/workflows/connector-ci-checks.yml` to change the suffix from:
- `[Unprivileged, Executed from Fork]`
To:
- `[Non-Blocking (Unprivileged) Test From Fork, pls run
`/run-connector-tests`]`
This affects 4 test steps total:
- Unit and Integration tests in the `jvm-connectors-test` job (lines
195, 200)
- Unit and Integration tests in the `non-jvm-connectors-test` job (lines
293, 298)
The conditional logic remains unchanged - the suffix only appears when
`needs.generate-matrix.outputs.creds-available == 'false'`.
## Review guide
1. `.github/workflows/connector-ci-checks.yml` - Verify YAML syntax is
correct, especially the backticks around the slash command
2. Check that all 4 test step locations were updated consistently
3. Confirm that the conditional logic
`needs.generate-matrix.outputs.creds-available == 'false'` remains
unchanged
## User Impact
**Positive:**
- Clearer indication in GitHub UI that unprivileged tests are
non-blocking
- Provides actionable guidance via `/run-connector-tests` slash command
- Reduces confusion for fork contributors about test failures
**Negative:**
- Longer test step names may be truncated in some GitHub UI views
## Can this PR be safely reverted and rolled back?
- [x] YES 💚
This change only affects display text and can be safely reverted without
impacting functionality.
---
**Link to Devin session:**
https://app.devin.ai/sessions/67080d0df8af414c81cfc74dcd9f50cd
---------
Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
## What
- Pin all GitHub Actions to their specific SHA1 hashes to reduce supply
chain attack risk
- Replaces version tags with specific commit SHAs
- Includes version comments for easier reference
- Changes generated with the pinact tool
See internal wiki page on supply chain security for further info
## How
Used the tool pinact to pin the sha for github actions.
## Review guide
<!--
1. `x.py`
2. `y.py`
-->
## User Impact
No impact
## Can this PR be safely reverted and rolled back?
- [x] YES 💚
- [ ] NO ❌
