-
Notifications
You must be signed in to change notification settings - Fork 659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build automation to verify dependency updates #2928
Labels
Comments
afs
added a commit
to afs/jena
that referenced
this issue
Jan 8, 2025
afs
added a commit
to afs/jena
that referenced
this issue
Jan 9, 2025
afs
added a commit
that referenced
this issue
Jan 9, 2025
afs
added a commit
to afs/jena
that referenced
this issue
Jan 13, 2025
afs
added a commit
to afs/jena
that referenced
this issue
Jan 13, 2025
afs
added a commit
to afs/jena
that referenced
this issue
Jan 13, 2025
afs
added a commit
to afs/jena
that referenced
this issue
Jan 15, 2025
afs
added a commit
that referenced
this issue
Jan 15, 2025
afs
added a commit
that referenced
this issue
Jan 15, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Run a workflow when dependabot submits pull requests.
This would not merge the changes.
This workflow would only be for dependabot dependency updates, not all PRs. Dependency updates don't add new files so there isn't going to be license header issues on new files which do arise in fetaure PRs.
If we are running automated checking, we could also grouping minor and patches because if an automated test throws up a problem, it is going to have to be manually sorted out; if it test passes then it is the combined set of changes.
The way to get it to be "dependabot" only is to use `if: github.actor == 'dependabot[bot]'. (Do not trust the AIs! - some get it wrong by trying to trigger on the branch name but that is the target of the PR, not the source.)
One downside is that it floods the actions log. The workflow runs on every pull request and then skips jobs, leaving a entry in the actions history. (If it triggered on the source branch name, it would not run and no log entry.)
We currently have a workflow ui.yaml. It does a partial build. If we conclude that the new dependency workflow works for the project, we could move some or all of the UI flow into one combined run.
The text was updated successfully, but these errors were encountered: