Install form layout is broken

[aloupfor]

• Gitea version (or commit ref): 1.1.0+61-g888dee3
• Git version: 2.10.1
• Operating system: Ubuntu 14.04.5 LTS
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

I'm installing gitea using this documentation: https://docs.gitea.io/en-us/install-from-source/.
Since this commit: a9de85d, the layout on the install form seems broken.
If I'am not wrong the fields were previously centred on the page.

Screenshot

[Fastidious]

AFAIK, the master holds daily changes, and can be broken at times. If you can't bare with that, stick to releases.

That been said, it is good to know when things are broken. The commit you mention was sent in by @strk, maybe he will take a look at it, and fix it.

[tboerger]

I wouldn't directly call it broken as still seems to work, but it looks bad/ugly.

[Fastidious]

@tboerger semantics. It looks pretty broken to me. Usable, but broken.

[lunny]

It's broken I think. @strk

[strk]

Tge only change in a9de85d is adding !important to some CSS and was done by less compiler. Are you sure that revertig that fixes the issue ? (Watch out for browser cache)

[aloupfor]

Here is what make think that it was since a9de85d.

$git log --oneline
888dee3 fix delete user failed on sqlite (#1321)
bd8fe49 fix wiki bugs (#1294)
dbabc35 Delete the useless code (#1335)
5586445 LFS: Return 404 for unimplemented endpoints (#1330)
9182a35 Show user OpenID URIs in their profile (#1314)
e158689 Add change-password admin command (#1304)
97ee889 Add captcha support to OpenID based signup
f00a4c8 Gitea OpenID-2.0 login has been tested with livejournal.com too
a9de85d Improve style of user OpenID setting page (#1324)
608cd54 fix gpg wrong column types

Before a9de85d commit:

$ git checkout 608cd54
$ make generate build
$ ./gitea web

After a9de85d commit:

$ git checkout a9de85d
$ make generate build
$ ./gitea web

[strk]

So it looks like the .css generated by my version of less compiler isn't good, if that's the case we should make the Makefile rule refuse to update index.css with an unexpected .css.

Can you please try to git revert a9de85d31d8ba3ce8801d03e66866e527f5f39d7 from master and try again ?
The only thing I really needed in that commit was the public/less/_user.less patch adding .openid.list selector beside .email.list one.

Can you help checking this @geek1011 ? (as my favorite resident CSS guy :)

[lunny]

@strk is this resolved?

[strk]

As of current master (bb14c97) it seems to be fixed, yes. Feel free to close (I don't have a close button)

[lunny]

@aloupfor please confirm what @strk said.

[sapk]

Change made by less version of @strk was revert in one of my commit @912b340d0d674b35ef04e66d00a10a8e4a02e82c (in master) because of re-generation of the file by less (maybe not the same version). So if it was the source of the bug it's corrected in master.

[lunny]

So let's close this. @aloupfor please feel free to reopen it.

[strk]

@sapk here I have lessc 1.6.3 (LESS Compiler) [JavaScript] - we'd need a check in the Makefile rule to make sure a specific version (range?) is used to recompile (or a "test-lessc" rule to make sure it matches the expected)

[lunny]

Maybe we need a command make less to compile the less to css and confirm it on make test. I think that will also ask all less file have been converted to .css and no .css have been changed with no .less change.

[strk]

One rule to generate the css exists: make public/css/index.css Having a "css" alias sounds good to me, and "test-css" to go with it (invoked as a dependency of "test" so we dont' have to change Drone). Note this is similar to what I tried to achieve with #1366, which was also affected by different versions of tooling...