Add gitlab CI #2200
Add gitlab CI #2200
Conversation
|
+1 for a mirror, as i think most of maintainers are used to github (but lets see their opinion) |
|
I initialized https://gitlab.haskell.org/haskell/haskell-language-server It's not an automatic mirror. I invited several people as maintainers. Issue tracker, PRs etc are disabled. |
great |
There was a problem hiding this comment.
LGTM but i would like to know the opinion from other maintainers before merge @Ailrun @pepeiborra @michaelpj (and everyone else)
| optional-packages: vendored/*/*.cabal | ||
|
|
There was a problem hiding this comment.
Being able to use vendored packages. If they don't exist, nothing happens. If they exist, they get picked up.
This is required because the network package is broken on M1 and needs a autoreconf (but cabal is unable to do so for you). So we do it manually and put it into this directory.
There was a problem hiding this comment.
it probably deserves a comment "Used by the M1 build script"
There was a problem hiding this comment.
hmm it is a somewhat standard way to include potential optional packages in any situation but a comment with an actual use case would be fine
There was a problem hiding this comment.
If it's (evidently) not obvious to the most active maintainers of this project, it definitely needs a comment for the rest of us poor mortals :)
There was a problem hiding this comment.
The comment could even point to the script where it's used!
There was a problem hiding this comment.
You know, github has a feature to add code suggestions ;)
There was a problem hiding this comment.
@hasufell i hope you dont mind i've added a pair of comments directly in your branch
What is the ultimate purpose? To ensure that HLS builds in those platforms or to produce binaries for distribution? |
Building binaries. I already did and added them to GHCup manually. |
|
@jneira what's with those reverse merges? |
they are the automatic merges made by github if you press the button to update branch with master (or made by mergifyio bot when you label it with |
Who will keep it up to date? Are there expectations on people other than @hasufell to do anything at all with this repo? (If there are, we should write them down in the contributing section) Do we expect that the CI will always pass if the other CI passes? Could it fail if the mirror gets out of date? If so, how would we fix that? Basically, I think it needs a section in the contributing guide that explains this stuff. |
Whoever does the release at the time of release preparation.
Yes, whoever is involved in cutting the release.
I think not
Not sure I understand. You'd basically push the release tag (manually or automatic, that's up to you) and the release build gets triggered. It may require some further work if you want automatic tar'ing etc. |
I have no idea what most of this stuff is for - but probably neither does anyone else, which is why some documentation would be great :) |
* Add gitlab CI * Add comment * Comment about vendored packages * Add link to gitlab ci config Co-authored-by: Javier Neira <atreyu.bbb@gmail.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Motivation
Building FreeBSD, Darwin aarch64 (M1), Linux armv7, Linux aarch64
Currently running pipeline looks good: https://gitlab.haskell.org/maerwald/haskell-language-server/-/pipelines/40810
Questions
This will require creating a repo at https://gitlab.haskell.org under the haskell namespace (I can do that). The main question is whether it should be a proper import (with all issues) or just a mirror to build releases.