Locking/auditing for tags #1091
Comments
|
Response from GitHub:
|
|
I am experiencing the same issues surrounding protecting tags. we are currently looking to migrate our source from another vcs into GitHub Enterprise, and this is a major sticking point for us. Another git related UI (cough gitlab cough) already has this functionality built in. In terms of sqa releases vs production releases, this is how we would be labeling releases, and if anyone with write privileges can delete a tag whenever they want, even on protected branches(which seems counter-intuitive), we have a problem. I agree with AlecBenzer that all three of his suggestions should be implemented, but in addition, why not make deleting tags on protected branches an admin/owner only task. this way, if one is applied by accident, it can be corrected, just not by everyone on the team with write access. |
|
I also have run into this limitation. I had to end up using branches instead, for marking released versions. It would be a lot cleaner if you could tag release versions instead. In that case, all branches would be WIP and all tags would be release. |
|
At the very least it would be nice to have a way to require tags to be annotated so that you can identify who pushed them. But more options around this would be very nice, as the @AlecBenzer pointed out there is pretty much nothing right now unless you restrict everyone to read-only. Personally I like using forks to help manage workflow but currently I am not able to do so because of the CI/CD tools I have inherited which do not support forks. |
|
GitLab has this feature: https://docs.gitlab.com/ee/user/project/protected_tags.html Really wish GitHub did. |
|
This is an accident waiting to happen, the ability to protect tags is very much needed. |
|
Our organization need this too. If not I will start thinking of moving to GitLab or so. |
|
This |
|
Just had the same issue in one of our releases, same as @io41. |
|
This would be a great feature for us too, surprised GitHub doesn't already have this |
|
When is this going to be implemented and added to GitHub Enterprise? |
|
I work at a 10-person medical imaging software development firm. We use Github extensively. We would very much like to have this feature. It exists in Gitlab already, and it would make Github more useful for us when working on FDA-regulated projects. In particular, it would make it easier for us to use Github as a 21 CFR Part 11 compliant document store. |
|
Just want to remind everyone in this thread that GitHub does not monitor this repository. Be sure to tell support that you need this feature, too. |
Hey @strugee! I'm Luke, a Product Manager at GitHub 😄👋. Actually we do monitor this repo (along with a number of other, popular community-run feedback repos) and appreciate all the comments very much! We want to let all the communities know that we're listening and that threads like this really help us to understand your problems and how we may improve 🤗. Although, if someone would prefer to contact support or post on our own forum instead, we'd certainly encourage that too, as it can be a little tricker to track all comments on community-run repos. Don't let that stop you though! If you've got a comment to make somewhere like this we want to encourage you to make it and know that we are listening 👂. In regards to this issue around tag protection☝️ – I happen to know that it's on our radar and that we've got people digging into the problem space as I speak ❤️. |
|
Ah neat, I must have missed the memo! Thanks @lukehefson, that's actually great to hear 👍 |
|
I've implemented this feature as a GitHub App. Looking for beta-testers. Check out https://github.com/apps/always-be-closing if you're interested. Any feedback would be appreciated at https://github.com/thoughtdealership/abc-users. |
TPS
added
permissions
parity
|
@mspiegel wrote:
I looked into the documentation of ABC, and it doesn't look like you've exactly implemented this feature. Instead you have implemented notification via GH issues when a tag is modified:
Which is a big improvement over no notification at all. Just recording the difference here for posterity. (Apparently this feature is also available from ABC Jr., which does not require read/write access to a repository.) |
|
@lukehefson are there any updates on this? : ) |
Not at the moment I'm afraid @SrodriguezO – it's something we're still looking into and hoping tackle soon. @SrodriguezO We'd love to hear more about your use case in the meantime! Why would tag protection be so useful for you and/or your team? |
|
For teams/workflows that store their versioning information in Git tags, it's important that these tags not be deleted or changed. |
|
@lukehefson We were thinking of automating releases on pushed tags, but currently anyone with write access to the repo can push tags. We'd like to limit this to repo admins or to a set of whitelisted users. We can already restrict pushing to specific branches; it'd make sense to be able to restrict tagging/releasing as well. |
|
2019 and still waiting :) |
|
@lukehefson This is still a major source of frustration to us in Optum. |
|
@lukehefson if you need more examples, we use a release tool that creates a commit on I'm moving to a system where these releases will get created by a CI tool instead so I can protect |
|
+1 |
|
+1. |
|
Please stop commenting +1. It doesn't add anything to the discussion, but it does generate a bunch of noise for people subscribed to this issue or watching this repository. Instead you can just use GitHub's reaction feature to react with 👍, which accomplishes the same thing but doesn't send hundreds of spurious notifications and emails. Thanks! |
* `ci.yml` is for every pull_request, `publish_master.yml` is
for nightly build which is published everytime master branch
is updated, and `publish_release.yml` is for stable version
release.
* `publish_release.yml` will run when we push a tag. The tag must
be a format "v.{major}-{minor}-{patch}"
Also, the version number in `fsproj` must match to the tag.
That's all we need when publishing.
* currently, protecting against pushing tag is not supported on
github, (see: isaacs/github#1091)
Which really sucks, so we should at least sign for every tag.
* For master realse, we publish both BouncyCastle version and Native
binary version to the NuGet. You can select either one by version suffix.
* For stable release, we only upload BouncyCastle version to the NuGet.
Native versions for each platform will only be on release page of GitHub.
* `ci.yml` is for every pull_request, `publish_master.yml` is
for nightly build which is published everytime master branch
is updated, and `publish_release.yml` is for stable version
release.
* `publish_release.yml` will run when we push a tag. The tag must
be a format "v.{major}-{minor}-{patch}"
Also, the version number in `fsproj` must match to the tag.
That's all we need when publishing.
* currently, protecting against pushing tag is not supported on
github, (see: isaacs/github#1091)
Which really sucks, so we should at least sign for every tag.
* For master realse, we publish both BouncyCastle version and Native
binary version to the NuGet. You can select either one by version suffix.
* For stable release, we only upload BouncyCastle version to the NuGet.
Native versions for each platform will only be on release page of GitHub.
* `ci.yml` is for every pull_request, `publish_master.yml` is
for nightly build which is published everytime master branch
is updated, and `publish_release.yml` is for stable version
release.
* `publish_release.yml` will run when we push a tag. The tag must
be a format "v.{major}-{minor}-{patch}"
Also, the version number in `fsproj` must match to the tag.
That's all we need when publishing.
* currently, protecting against pushing tag is not supported on
github, (see: isaacs/github#1091)
Which really sucks, so we should at least sign for every tag.
* For master realse, we publish both BouncyCastle version and Native
binary version to the NuGet. You can select either one by version suffix.
* For stable release, we only upload BouncyCastle version to the NuGet.
Native versions for each platform will only be on release page of GitHub.
|
This feature is like drinking water, my company wants to move from gitlab to github but this unbelievable 3 years issue is preventing us to do so. |
|
+1 |
|
Almost 3 years and still waiting. This issue is tagged WIP, so any update on this? |
|
We just moved to a CI/CD pipeline using GitHub Actions and wanted to deploy releases using tags. It works perfectly and then wanted to protect tag creation only to know that wasn't possible. We would greatly appreciate if this feature request gets implemented sooner than later. |
|
Check this issue opened time |
|
@lukehefson any updates on this? Is there anyway we can get any visibility into this WIP other than tagging you directly? |
|
This feature should be highly prioritized, we at our company manage to do without it for now but as we grow it will become mandatory and we don't want to move to gitlab for this, github is pleasant |
|
It's a little surprising that this hasn't been added to github yet, especially given how essential to many teams flows tags are. |
|
We really need this. Whats the status? @isaacs |
|
Just came across this today, Github now allows users to submit feature requests via https://support.github.com/contact/feedback . Probably worthwhile for us to do since this repo is only kinda tracked by github per #1091 (comment) |
|
@HeatherLemieux Apologies for the slow response – I've been out of the office for a break. I'm no longer part of a team that has an influence on this part of our product so I'm unable to state when it may be addressed or how. I do however know that the team responsible for this area is very aware of it!
Yes! That's now the best way to register your feedback and I'd highly encourage you to do so. It will lead directly to the team who owns this part of the product 😄 |
|
I believe this issue is tracked here now: But it seems that there is not much progress. |
|
Love this feature,should be considered. |
and others
Right now, it's basically impossible to have any protection around tags:
Any number of things could be done to improve this:
The text was updated successfully, but these errors were encountered: