1
1
Fork 1
mirror of https://github.com/go-gitea/gitea.git synced 2024-04-19 21:13:50 +02:00
Commit Graph

22 Commits

Author SHA1 Message Date
techknowlogick a346a8c852
bump to use go 1.22 (#29119) 2024-02-14 18:19:57 +00:00
techknowlogick b32998b3f5
set version in snapcraft yaml 2023-09-13 23:20:46 -04:00
Sienna Lloyd e986265ecb
update snap package (#27021) 2023-09-12 12:47:53 +00:00
wxiaoguang faa28b5a44
Move public asset files to the proper directory (#25907)
Move `public/*` to `public/assets/*`

Some old PRs (like #15219) introduced inconsistent directory system.

For example: why the local directory "public" is accessed by
`http://site/assets`? How to serve the ".well-known" files properly in
the public directory?

For convention rules, the "public" directory is widely used for the
website's root directory. It shouldn't be an exception for Gitea.

So, this PR makes the things consistent:

* `http://site/assets/foo` means `{CustomPath}/public/assets/foo`.
* `{CustomPath}/public/.well-known` and `{CustomPath}/public/robots.txt`
can be used in the future.

This PR is also a prerequisite for a clear solution for:
* #21942
* #25892 
* discourse.gitea.io: [.well-known path serving custom files behind
proxy?](https://discourse.gitea.io/t/well-known-path-serving-custom-files-behind-proxy/5445/1)

This PR is breaking for users who have custom "public" files (CSS/JS).
After getting approvals, I will update the documents.

----

## ⚠️ BREAKING ⚠️

If you have files in your "custom/public/" folder, please move them to
"custom/public/assets/".

---------

Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Giteabot <teabot@gitea.io>
2023-07-18 18:06:43 +02:00
techknowlogick d9763d605d
Downgrading Snap to build with node/18 instead of node/20 2023-07-16 22:28:52 -04:00
silverwind 51b130831e
Upgrade snap to node 20 (#24990)
Followup to https://github.com/go-gitea/gitea/pull/24524. Now there is a
[node 20 snap](https://snapcraft.io/node), so let's upgrade to it.
2023-05-29 22:41:56 +02:00
Yarden Shoham 9745c33e9e
Remove unnecessary whitespace in snapcraft.yaml (#22090)
Signed-off-by: Yarden Shoham <hrsi88@gmail.com>
2022-12-10 08:31:16 -06:00
techknowlogick 3d12018a74
switch to node18 for snapcraft 2022-08-18 12:25:50 -04:00
techknowlogick 24d39ee6b7
revert to node14 for snapcraft 2022-02-01 15:10:55 -05:00
techknowlogick 70e614b9da
build with node16 in snap (#18508) 2022-01-31 17:52:12 -05:00
Andrei Yankovich b5f5eab913
Removable media support (#16136)
Add support removable media for snap version of gitia.
for get more info about removable media interface see the snapcraft [documentation](https://snapcraft.io/docs/removable-media-interface)
2021-06-11 14:51:05 -04:00
silverwind 1bf7d71a0a
Consolidate Logos and update README header (#14136)
* Consolidate Logos and update README header

- Remove unused `logo-lg.png`, `logo-sm.png` and `logo-192.png`.
- Consolidate `favicon.svg` and `logo.svg` to just `logo.svg`.
- Remove Safari Mask icon, it seems to work fine with just `favicon.png` (no SVG support).
- Remove Fluid Icon. It only served Firefox and SVG works just fine there.
- Update customization instructions.
- Update README.md to use SVG icon, increase logo size and center it and badges.

* Update README_ZH.md

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>

* Update README_ZH.md

Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2021-01-01 14:04:35 -05:00
Kyle D 4cd94e3689
gitea png to logo (#13974)
* gitea png to logo.svg

* gitea safari svg to logo

* minify svgs

* Update english docs

* Update missing section on customizing logo
2020-12-18 20:17:27 -05:00
techknowlogick 88b585c2e0
Store repository data in data path if not previously set (#13991)
* Store repository data in data path if not previously set

* update docs

* Update docs/content/doc/advanced/config-cheat-sheet.en-us.md

Co-authored-by: silverwind <me@silverwind.io>

* update docs

Co-authored-by: silverwind <me@silverwind.io>
2020-12-15 16:52:59 -05:00
Jeremie Deray 870fd53320
set git-core paths in snap (#13711)
Signed-off-by: artivis <deray.jeremie@gmail.com>

Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2020-11-30 13:49:11 -05:00
Alan Pope b609a25014
Add logic to build stable and edge builds (#12052)
This adds some logic to enable the snapcraft builds of the gitea snap to create both builds of the latest tip of master for edge channels, and stable releases.

The logic simply looks for a new upstream release in github, and if that latest tagged release is not the same as the release in the candidate channel in the snap store, then it must be new, and so we checkout that tag and build that. If the current released tag is the same as what's in candidate, we build whatever is in git master.

The process for using this is:

Initially: When this lands, it will build the latest stable release of gitea and push to the edge channel in the snap store. Someone on the release team can go to https://snapcraft.io/gitea/releases and release that build to stable and candidate.

Ongoing: The next build to be triggered will be a git master build, and can just sit in edge, nothing for the release team to do.

On new release: The next build triggered will contain the stable release, and will be published to edge. Someone on the release team can login to the above URL and release that again to stable & candidate. Alternatively they can release to candidate, do some additional testing on that release before releasing to stable.

Hope that all makes sense. Questions / comments welcome.

I'm super keen to see stable releases of Gitea in the stable channel of the Snap Store. I'd like to promote it but I can't really until it's in stable.

Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2020-07-17 13:27:00 -04:00
Alan Pope b9df5da1f4
Limit snap build architectures (#11346)
Builds will fail on s390x, i386 and ppc64el because we depend on nodejs, which is only published for armhf, arm64 and amd64. This change merely tells the snap build farm to not waste time trying to build on architectures will will guarantee failure. Apologies for overlooking this in our previous PR.

Example build failures can be seen at [i386](https://launchpad.net/~build.snapcraft.io/+snap/53d5570c233b8b3663242f8d94dc21ad/+build/945935), [ppc64el](https://launchpad.net/~build.snapcraft.io/+snap/53d5570c233b8b3663242f8d94dc21ad/+build/945939), [s390x](https://launchpad.net/~build.snapcraft.io/+snap/53d5570c233b8b3663242f8d94dc21ad/+build/945940)
2020-05-09 12:39:19 +08:00
Sergio Schvezov b09ec508c3
update snapcraft.yaml for core18 and latest features (#11300)
Removing some of the complexity, together with the install and
configure hook.

Signed-off-by: Sergio Schvezov <sergio.schvezov@canonical.com>
2020-05-08 21:21:28 +01:00
silverwind 3f42934b9a Remove explicit 'generate' calls, fix release task (#9288)
* Remove more explicit 'generate' calls

`generate` is now implicit during `build` since #9114, it is no longer
necessary or desired to specify it explicitely.

* add js,css,generate dependencies to release task

* remove generate warning as per @lunny
2019-12-08 18:56:59 +02:00
Lunny Xiao 83b90e4199 Use vfsgen instead of go-bindata (#7080)
* use vfsgen instead of go-bindata

* fix templates

* fix fmt

* vendor vsfgen
2019-06-03 00:43:47 +03:00
Mura Li 25c49cf930 Update build tags for sqlite_unlock_notify (#5144) 2018-10-23 19:47:59 +08:00
Thorben 14f16d6c2e snap-packaging for gitea (#2568)
* Modify tbraeutigam/gogs-snap for gitea

* Fix building on 16.04 (manually build go-bindata).
-> add _source.tar.bz2 to .gitignore (used by snapcraft cleanbuild)

* Streamline Snap packaging:
 - Take advantage of install-hooks (snapd 2.27)
 - Use snapctl configuration storage for unchanging values

* Move to using Snap Hooks for configuration

* Missed re-adding daemon statement

* Fix two warnings from Codacy.
2018-05-09 22:52:51 +08:00