new release page

[raveit65]

copied from #13 (comment)

@raveit65 @flexiondotorg

The release server just works.

Here is a demo release website: https://mate.zhcn.cc/
I use this repo for test: https://github.com/yetist/mate-common

[yetist]

@raveit65 @flexiondotorg

This is the step by step to use the release-server:

1. download the last release-server binary from here:
   https://github.com/yetist/release-server/releases
   then save the release-server in $PATH directory and give it execute permission.
2. download the example config file from here:
   https://github.com/yetist/release-server/blob/master/release-server.toml.example
   and rename it to release-server.toml, put it in /etc/xdg/release-server/<VERSION>/release-server.toml
3. edit the release-server.toml file.
   In the [path] section, to setup where the tarballs saved, these path maybe used in static http server, such as apache, nginx or caddy.
   In the [security] section, there are there item need to set:
   a) api_secret: please use some random characters. Then, goto the travis website, select one repo which want to use auto release, create new hide environment variable named API_SECRET and set it to use the the same value.
   b) allow_repos can simple setup to * for allow any repo, or write every repos like mate-desktop/caja, mate-desktop/mozo etc.
   c) allow_ips can setup to the travis-ci ip address, they can found here: https://docs.travis-ci.com/user/ip-addresses/
4. run release-server in the server.
5. goto the repo which to use github release page, append the notify_servers into .travis.yml.
   The example is here: https://github.com/yetist/mate-common/blob/master/.travis.yml
   The url is provide by the release-server, according the the release-server.toml.

Then, if you create tag for some repo, and push it to the github, the github release page will created, and the tarballs will saved in the custom release server.

You can try it and hope to go well.

[raveit65]

The pre-release folder wasn't a public folder. We use it in the past to share tarballs for testing between team members.
And is there a way to upload tarballs by hand? Same what we did here https://release.mate-desktop.org
People with access to this website cold upload a tarball there, which was moved to public download folder internally.

[yetist]

This is two questions:

1. Publish drafts and pre-release versions:
   Github supports the release of drafts, pre-releases, and release versions. To automate them, you need to enable the settings in .travis.yml:

releases:
  draft: false
  prerelease: false
  ...

2. Custom server listing directory:
   The release-server only download tarballs from github release page and save them into some directories on the server.
   Whether to display these directories publicly, or to require authentication to access these directories, can be changed by modifying the http server configuration.

[yetist]

The whole process is like this:

local -> travis -> github release -> http server.

local: git push TAG =>
travis: make dist -> publish to github release -> notify http server =>
http server: download tarballs from github -> save them into static http directory =>
person: visit url, to see the tarballs in http server.

[raveit65]

Ok, so the folder stucture is what we used at github release page and doesn't have anything to do with our old pre-relase and release folder to upload tarballs to our server.

then save the release-server in $PATH directory and give it execute permission.

This is /usr/bin ? Or can i put the binary in a home folder of a fresh account?

I think a systemd unit file would be nice and comfortabel for starting the binary.
Hopefully i will find some time over the weekend to configure the server.

[yetist]

Yes, you can set the directory as needed.
You can also use the old method instead of the draft and pre-release provided by github.
The release-server can be placed in any suitable directory as long as systemd can start it.
Here is demo for that:

[Unit]
Description=Release server
After=syslog.target
After=network.target

[Service]
LimitNOFILE=65535
RestartSec=2s
Type=simple
User=www-data
Group=www-data
ExecStart=/usr/bin/release-server
Restart=always

[Install]
WantedBy=multi-user.target

[raveit65]

@yetist
Which characters can I use for the api_secret token?
Letters, numbers, upper and lower case, special characters ?

[yetist]

Letters, numbers, upper and lower case is ok, except space and Tab.

[flexiondotorg]

@raveit65 @sc0w The server was upgraded to Debian 10 yesterday 😃

[flexiondotorg]

One question regarding the new release system. The current system updates an RSS feed when a new release is published:

• https://pub.mate-desktop.org/rss.xml

New feed entries are automatically posted to social media. Where will the RSS feed reside for the new release system?

[yetist]

@raveit65

According to your configuration files, https://pub.mate-desktop.org/releases is used to receive
the notification, but the real service address is http://<IP>:9090/release, Do you setup the reverse proxy so that they access the same service? If not, the notify_server should be set to http://<IP>:9090/release.

I used caddy, the configuration file is as follows:

# vim: set filetype=caddy ts=4 sts=4 : 
mate.zhcn.cc {
        root /srv/http/mate-desktop/
        log /var/log/caddy/mate-desktop.log
        gzip
        index        index.html
        browse
}

post.zhcn.cc {
        log /var/log/caddy/mate-desktop.log
        proxy / http://localhost:9090
        limits 20mb
}

The release-server's config file:

host = "localhost"
port = 9090

So I can use the https://post.zhcn.cc/release as the notify_servers in .travis.yml:

    notify_servers:
      - https://post.zhcn.cc/release

[yetist]

Please check the server with:

$ curl -v -d 'a=b' https://pub.mate-desktop.org:9090/release

If a valid service is tested, it responds {"status":"invalid request."}:

$ curl -v -d 'a=b' http://localhost:9090/release
*   Trying ::1:9090...
* TCP_NODELAY set
* Connected to localhost (::1) port 9090 (#0)
> POST /release HTTP/1.1
> Host: localhost:9090
> User-Agent: curl/7.66.0
> Accept: */*
> Content-Length: 3
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 3 out of 3 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Content-Type: application/json; charset=utf-8
< Date: Sat, 05 Oct 2019 01:20:58 GMT
< Content-Length: 29
< 
* Connection #0 to host localhost left intact
{"status":"invalid request."}

[yetist]

It seems the server is running, but what is the result when you running curl at your working pc? If there is no result, maybe you should check the iptables at server.