3 ms·

I am not a big shop - I work on a team on the order of 10 We use GitLab as our "one place to do the entire software development lifecycle". It's a really good

by nawgz 5y ago

I am not a big shop - I work on a team on the order of 10 We use GitLab as our "one place to do the entire software development lifecycle". It's a really good CI/CD runner in my opinion, the .gitlab-ci.yml files are expressive and enable reuse thru a pretty nice inheritance model, and integrating new service (container) builds is literally 4 lines of code to have every push build a new container and put it in GitLab container registry. It also makes developing NPM packages a breeze, thru the same reuse of CICD files we can drop 4 lines into an JS/TS repo and have it publish to the built-in package registry on tags. On top of this, its ticketing system is worlds better than GitHub's. Less clicks, more available relationships & tags, more views, inheritance/rollup via the group structures you can put in place let you view tickets at a repo / group level, and since you can create trees from the groups you can have reasonably expressive places to view groups of issues. Finally - it's all free! We're using free tier self-hosted, and it's far superior to my experience with GitHub paid. I admit, we have decent (read: overscaled) hardware to self-host on, but GitLab really does offer a ton of useful tools to building software.

shortstuffsushi 5y ago
> we can drop 4 lines into an JS/TS repo and have it publish Could you talk a bit about this, or link out to any docs they've got for this? I'm curious about setting that up
- nawgz 5y ago
  I will give a high-level overview. Essentially, it is a workflow runner. You can set up "jobs" in a "pipeline" (dependency graph of jobs), and each job is just a bit of yaml. This yaml has individual keys controlling things like running a script, configuring the environment, controlling the docker image executing the job, etc.. These jobs / yaml blobs can be included into other files / projects using another one of these keys, "including" another job/pipeline via configuring the path to the repo & path to the file you want to import. You can override any properties really easily on these includes as well. Anyways, my .gitlab-ci.yml for building a container (any repo containing a top-level Dockerfile works zero-config, non-top-level can be configured) looks like this include: - project: 'public-tools/gitlab-extensions' ref: master file: '/.gitlab/ci/Docker-build.gitlab-ci.yml' Then of course that file does the things to run a `docker build` script with secrets passed as build args etc
- rossmohax 5y ago
  You don't even need to do that. Gitlab has repository configuration option to take CI config from another place. So you can have code only repo being built by a CI pipeline described elsewhere.
wdb 5y ago
NPM Private registry doesn't really work for me with Yarn and NPM v7 when trying to run binaries. This is a major blocker for a lot of things. Also the `npm install` is really flaky multiple times a day I get 404s for packages in the private registry. You need to keep retrying jobs that use that command until succeeds.
- nawgz 5y ago
  I experienced some initial configuration pain with their Package Registry, but after generating PATs for local use and passing secrets thru the CICD build runner nicely - and using yarn - I have had no issues publishing nor installing my own private modules. Here are the commands I suggest you run to authenticate your local machine to GitLab: yarn config set "@example:registry" "https://gitlab.example.com/api/v4/packages/npm/" yarn config set //gitlab.example.com/api/v4/packages/npm/:_authToken "<your PAT here>" yarn config set //gitlab.example.com/api/v4/projects/:_authToken "<your PAT here>" When you need to debug, the output of yarn config list is pretty concise and helpful. Be aware there can be local per-config folder so if you have trouble in a specific project you should issue that command there and check for incorrect registry settings etc. I also suggest you fully commit to yarn or npm, they are definitely different enough to be awkward to combine.
  - wdb 5y ago
    > I also suggest you fully commit to yarn or npm, they are definitely different enough to be awkward to combine. I can't even migrate to Yarn because of issues. Try using a package that has binary (`bin` in `package.json`) or other metadata and publish on your private NPM registry and then use it with Yarn or NPM v7 you won't be able to as it strips away this metadata. For example, if I want to push a patched version of Playwright to my NPM registry. I can't use it if I don't use NPM v6. Also the daily 404s errors when trying to install your private NPM packages which requires retry your jobs isn't help either. Sadly it's not an important enough issue for them to fix. I am really wondering if Gitlab is using their products themselves.

by nawgz 5y ago

shortstuffsushi 5y ago

> we can drop 4 lines into an JS/TS repo and have it publish Could you talk a bit about this, or link out to any docs they've got for this? I'm curious about setting that up

nawgz 5y ago
I will give a high-level overview. Essentially, it is a workflow runner. You can set up "jobs" in a "pipeline" (dependency graph of jobs), and each job is just a bit of yaml. This yaml has individual keys controlling things like running a script, configuring the environment, controlling the docker image executing the job, etc.. These jobs / yaml blobs can be included into other files / projects using another one of these keys, "including" another job/pipeline via configuring the path to the repo & path to the file you want to import. You can override any properties really easily on these includes as well. Anyways, my .gitlab-ci.yml for building a container (any repo containing a top-level Dockerfile works zero-config, non-top-level can be configured) looks like this include: - project: 'public-tools/gitlab-extensions' ref: master file: '/.gitlab/ci/Docker-build.gitlab-ci.yml' Then of course that file does the things to run a `docker build` script with secrets passed as build args etc
rossmohax 5y ago
You don't even need to do that. Gitlab has repository configuration option to take CI config from another place. So you can have code only repo being built by a CI pipeline described elsewhere.

wdb 5y ago

NPM Private registry doesn't really work for me with Yarn and NPM v7 when trying to run binaries. This is a major blocker for a lot of things. Also the `npm install` is really flaky multiple times a day I get 404s for packages in the private registry. You need to keep retrying jobs that use that command until succeeds.

nawgz 5y ago
I experienced some initial configuration pain with their Package Registry, but after generating PATs for local use and passing secrets thru the CICD build runner nicely - and using yarn - I have had no issues publishing nor installing my own private modules. Here are the commands I suggest you run to authenticate your local machine to GitLab: yarn config set "@example:registry" "https://gitlab.example.com/api/v4/packages/npm/" yarn config set //gitlab.example.com/api/v4/packages/npm/:_authToken "<your PAT here>" yarn config set //gitlab.example.com/api/v4/projects/:_authToken "<your PAT here>" When you need to debug, the output of yarn config list is pretty concise and helpful. Be aware there can be local per-config folder so if you have trouble in a specific project you should issue that command there and check for incorrect registry settings etc. I also suggest you fully commit to yarn or npm, they are definitely different enough to be awkward to combine.
- wdb 5y ago
  > I also suggest you fully commit to yarn or npm, they are definitely different enough to be awkward to combine. I can't even migrate to Yarn because of issues. Try using a package that has binary (`bin` in `package.json`) or other metadata and publish on your private NPM registry and then use it with Yarn or NPM v7 you won't be able to as it strips away this metadata. For example, if I want to push a patched version of Playwright to my NPM registry. I can't use it if I don't use NPM v6. Also the daily 404s errors when trying to install your private NPM packages which requires retry your jobs isn't help either. Sadly it's not an important enough issue for them to fix. I am really wondering if Gitlab is using their products themselves.