dependabot-core
dependabot-core copied to clipboard
dependabot
Provide option to configure format of branch name
From @edkellena on January 9, 2018 15:40
Hey, It would be super awesome if we could specify some format for the branch name created.
Use-case:
Our CI system sees a PR raised and will run through a build process that generates a Docker image and tags it with the branch name. Unfortunately Docker tags have more limited scope than Git branches...
A tag name must be valid ASCII and may contain lowercase and uppercase letters, digits, underscores, periods and dashes. A tag name may not start with a period or a dash and may contain a maximum of 128 characters.
The / in the Dependabot branches is causing that tagging to fail. We can work around this with some awk/shell wizardry I guess, but would be nice not to have to do this.
Copied from original issue: dependabot/feedback#72
Thanks for the feedback @edkellena.
It's a totally legit request, but I'm not keen on changing things on Dependabot's side for a couple of reasons:
- branch name generation is already quite complicated and I don't want to add more considerations to it
- there's no obvious place to put the setting in the frontend at the moment
Do you have control over the build process on your side? I'm hoping it would be straightforward for you to sanitize the branch name when generating a tag.
From @edkellena on January 9, 2018 22:12
Fair enough 👍 I did wonder whether it would be a fruitless ask! Would be happy to attempt a PR for the generation, but without the UI setting available, that would be a bit pointless.
I do have some very hacky workaround at the moment, which I'll try to unhack soon. Cheers though!
You could always monkey-patch it, now whether or not you should...
module Dependabot
class PullRequestCreator
class BranchNamer
def new_branch_name
super.gsub(TO_REMOVE, TO_REPLACE)
end
end
end
end
if you use dependabot v2 just add to your dependabot.yml
pull-request-branch-name:
separator: "-"
https://docs.github.com/en/github/administering-a-repository/configuration-options-for-dependency-updates#pull-request-branch-nameseparator
I'd like to bump this request - our CI system also requires that branch names only be so long.
What we don't require is that our branch names be semantically accurate - something like dependabot_20210625.1544 would work just as well as a descriptive name, given that the pull request title and description, as well as the contents, are enough to go on.
I do understand that the logic in branch_namer is moderately complex, and it would be hard to set up some sort of way to provide a format string, but maybe a flag to toggle the type of branch name format? Or even an option to leave off certain parts (e.g., package manager) and/or truncate the whole thing (from the start or the end) to a given length?
Right now, a lot of our dependabot PRs are unusable without a dev having to manually create a new branch and PR.
Is there an option to change the branch name? I think it is too long, and maybe it would be better and cleaner for the branch to include only dependabot/updated-dependencies.
Why was this closed? The following dependabot branch breaks docker tags dependabot/npm_and_yarn/shelljs-0.8.5. I feel like the obvious fix would be to switch the branch naming convention to dependabot/npm_and_yarn/${lib_name}-${uuid.slice(0, 8)}. We will be forced to do this in our own code. There's already an option in the yaml file for pull_request_branch_name but the only sub-option is separator
I don't see why the version-number needs to be in the branch name. What's the purpose of that? In any case, it makes sense to make it an option to provide a custom branch name.
+1 for this request. Our dependabot build fail because we use ACR. ACR requirements: Repository names can only include lowercase alphanumeric characters, periods, dashes, underscores, and forward slashes. Reference
Sample error from the pipeline:
Message: Image name 'dependabot/nuget/Moq-4.1/something/something:2.2.0-linux-amd64' is invalid.
The acceptable patterns are 'repository' or 'repository:tag'.
The repository and tag names follow the standardized docker repository and tag naming conventions.
Tag templates are supported within '{{' and '}}'.
I'm going to re-open since there's so much interest here. I'm not sure that we'll choose to solve this by providing the option, but clearly there's a problem that needs solving in one way or the other.
FWIW Another data point:
Our CI end-to-end tests check PRs (including dependabot PRs) through Cloudflare preview deploys. At some point, for branch names longer than ~28 characters, Cloudflare adds an (undocumented 🙈) 4-random-letter suffix to the otherwise deterministic preview URL. This makes the CI fail dependabot PRs with long branch names as it can't easily compute the preview URL by itself.
For us, a dependabot.yml option to limit the dependabot branch name length (e.g. to 28) would be a great start.
Hi!
If I understand correctly, there’s two issues reported here:
- Branch name using not acceptable characters as separators.
- Branch name being too long.
The former is already fixed by the pull_request_branch_name.separator option. For the latter, truncating the max branch name length through a pull_request_branch_name.max_length configuration seems like the easiest way, specially because we already have pull request creation logic in place to do that.
This will require a few internal changes but it seems like a big part of it is already in place.
@deivid-rodriguez The other issue is the use of uppercase chars, which e.g. Azure Container Registry (ACR) does not support.
The branch-length problem also regularly hits us, when using GCP Workload Identity Federation with the following error:
google-github-actions/auth failed with: retry function failed after 1 attempt: failed to generate Google Cloud federated token for projects/XXX/locations/global/workloadIdentityPools/YYY/providers/ZZZ: (400) {"error":"invalid_request","error_description":"The size of mapped attribute google.subject exceeds the 127 bytes limit. Either modify your attribute mapping or the incoming assertion to produce a mapped attribute that is less than 127 bytes."}
This emerges from the Token-Format where the subject is the repository- and branch-name, which in combination with the length limitation on GCP for the subject.
The only workaround we currently have is to rename the branch and create a new PR, because the old one is tied to the branch name, so that our checks can work as expected.
Providing/Exposing the max-length configuration for depenabot.yml really would help us.
I am also facing the same issues with branch name length. We are using harness to deploy our applications and it is allowing only 63 characters for the branch name.
It would be great if we get the option for max-length
The option to configure maximum branch length has been released here in v0.213.0 (https://github.com/dependabot/dependabot-core/blob/main/CHANGELOG.md#v02130-31-october-2022) and in dependabot-gitlab in version v.0.30.0 (https://gitlab.com/dependabot-gitlab/dependabot/-/releases/v0.30.0).
@TomNaessens Thank you for the update. How do I specific this specific version in depdendabot.yml. I am receiving below error
The property '#/updates/0/pull-request-branch-name' contains additional properties ["max_length"] outside of the schema when none are allowed The property '#/updates/1/pull-request-branch-name' contains additional properties ["max_length"] outside of the schema when none are allowed
I don't see this option here https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file.
Please let me know what I am missing
I think the problem is that while the option was added to this library, we're not yet making use of it in the GitHub service, nor have yet exposed any configuration option for it, since that requires a number of internal changes. But this feature is definitely closer now than it was before!
@ramachandran-murugaian-kr @deivid-rodriguez I agree.
To my understanding what @TomNaessens referred to is that the internal branch namer now has the ability to generate branch names of limited length (branch_name_max_length). Maybe Tom was implying that a quick solution for this issue would be to expose and document this option to the YAML config (maybe as pull-request-branch-name.max-length)?
We are also looking forward to a feature which enables the customization of the dependabot branch name. The issue we have is that we create a lot of resources based on the branch name. Our dependabot builds fail, because resource names (e.g. included in domain names, in AWS resources, ...) are reaching the allowed byte limits.
For example a branch name like dependabot-[unique ID] where unique ID could e.g. be just an epoch timestamp or something like it would be awesome.
In our case, we are running some k3s infrastructure and we are limited to branch names of 63 characters https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set
Exposing the max-length will be great!
I just came across an issue being caused by long PR names, and was surprised to find that there is no way to control how PR names are formatted.
My Dependabot target-branch is dependabot/main. When Dependabot creates a PR, it is created using the following format:
dependabot/{packageManager}/{targetBranchName}/{packageName}. In my case, this becomes dependabot/nuget/dependabot/main/{packageName}.
I'd love the flexibility to be able to omit the target-branch value from being included in the PR name.
This would allow my Dependabot PRs to be: dependabot/nuget/{packageName}, as I originally intended.
👍🏼
Yeah, it would be nice if there would be an option that would allow you to enter custom branch names in the pull-request-branch-name option and not just the separators.
Alternatively, you could look at Renovate's insane array of configuration options 😄: https://docs.renovatebot.com/configuration-options/
Please, it's opened since 2018 😢
We use cloud tools that fail because of long branch names. This makes using dependabot really annoying. I would really love if this quick win could get a tiny little bit more love :(
Had to resort to this in my Github Workflow file:
# Sanitizes dependabot branch names
echo "suffix=-$HEADREF" | sed -r 's/[-.]+/_/g' >> $GITHUB_OUTPUT
We use cloud tools that fail because of long branch names. This makes using dependabot really annoying.
The length is already configurable:
- https://github.com/dependabot/dependabot-core/pull/5338
And we're talking about adding some reasonable per-platform defaults too:
- https://github.com/dependabot/dependabot-core/issues/7564
What is not captured in those is modifying the format of branch names, which is much more complex then just truncating to a max length. That's what this ticket is about.
We use cloud tools that fail because of long branch names. This makes using dependabot really annoying.
The length is already configurable:
And we're talking about adding some reasonable per-platform defaults too:
What is not captured in those is modifying the format of branch names, which is much more complex then just truncating to a max length. That's what this ticket is about.
Although the max length is configurable it doesn't seem exposed in the GitHub actions config options, https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
How feasible is it to add this in? Is there a repo for the GitHub action, I'd be happy to try and contribute towards this but unsure if the action code is in a private repo or one that doesn't accept contributions from the community.
Also waiting, and really looking forward for the exposure of the branch length configurability so that in can be set in the dependabot.yml, as the branch name normally provides the necessary uniqueness for our Helm releases. As known, Helm & Kubernetes restrict the length for names that we can give resources to be created. We currently need ugly workarounds in order to make our Helm releases work in our automated CI/CD setup, in which we build the application with the version change provided by the dependabot MR (as we work with GitLab), deploy it to the Kubernetes cluster and run automated e2e-tests on it.
