The secret is added to the repo already.
Right now this only publishes commits to main branch to the
"latest/edge" snap channel, but if this is successful we can add more
workflows/logic to be able to publish RCs/fully tagged versions too.
---------
Co-authored-by: Nicolas <bircni@icloud.com>
This is a step towards potentially splitting command groups into their
own folders to clean up `cmd/` as one folder for all cli commands.
Returning fresh command instances will also aid in adding tests as you
don't need to concern yourself with the whole command tree being one
mutable variable.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
To align with how GitHub requires additional explicit user interaction
to make a repo private, including informing them of implications on what
happens if they do.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This would allow developers to keep a local file that'd add personal
makefile targets for niche convenience customization without having to
have the git workspace polluted with uncommitted changes.
---------
Signed-off-by: techknowlogick <techknowlogick@gitea.com>
Entra ID users should use the OIDC oauth2 provider.
They will still be shown if the instance has a previous Azure AD source
configured.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Similar to how we have ignores for other tooling (eg vscode & IntelliJ)
we shouldn’t include these files in our repo. If they get added then
we’d have to maintain them and keep them up to date, and personally
there are too many tools to do that for.
`timetzdata` is already used in the docker images, this includes them
for the binary release files too.
Related to #33235 (I don't have a windows machine setup to test this
though)
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This will allow instance admins to view signup pattern patterns for
public instances. It is modelled after discourse, mastodon, and
MediaWiki's approaches.
Note: This has privacy implications, but as the above-stated open-source
projects take this approach, especially MediaWiki, which I have no doubt
looked into this thoroughly, it is likely okay for us, too. However, I
would be appreciative of any feedback on how this could be improved.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
We don't need to have polyfills down to Node v4. Some of our deps have
polyfills, and don't utilize the built-in implementation if available.
While this does decrease our package graph, I haven't been able to
notice any decrease/increase in page load times, although that could
likely be just because it's already pretty fast.
Nolyfill is https://github.com/SukkaW/nolyfill
updates to files generated with:
```shell
npx nolyfill install
npm update
```
Before this is/isn't merged, I'd be appreciative/thankful for other's
insights.
Edit: This isn't due to a specific individual. I am generally supportive
of them and their dedication to backward compatibility. This PR is due
to not needing those imports for our minimum requirements. Please don't
take this PR as commentary on anyone's character.
---------
Co-authored-by: silverwind <me@silverwind.io>
Reduce accident closing of tickets only to re-open them right away. This
aligns the text on these buttons with what GitHub has.
Commit is authored by @LazyDodo, and was committed to the Blender fork
by @brechtvl
Background details:
https://projects.blender.org/infrastructure/gitea-custom/pulls/7
Co-authored-by: Ray Molenkamp <github@lazydodo.com>
I'm temporarily unable to properly evaluate actuated runners, and so I'm
switching back to hosted runners until I am able to focus on that again.
---------
Co-authored-by: silverwind <me@silverwind.io>
* Rootless/ful docker images build separately
* Vendor go modules outside docker to speed up the build
Thanks to Alex Ellis for these suggestions (and actuated runner build
time)
