diff --git a/README.md b/README.md index 461982a..c463e3f 100644 --- a/README.md +++ b/README.md @@ -6,18 +6,19 @@ -# eng: Joyent Engineering Guide +# eng: Triton Engineering Guide This repo serves two purposes: (1) It defines the guidelines and best -practices for Joyent engineering work (this is the primary goal), and (2) it +practices for Triton engineering work (this is the primary goal), and (2) it also provides boilerplate for a Triton (formerly known as SDC) project repo, giving you a starting point for many of the suggestion practices defined in the guidelines. This is especially true for node.js-based REST API projects. **You probably want to be looking at the -[actual Joyent engineering guide at docs/index.md](docs/index.md).** +[actual Triton engineering guide at docs/index.md](docs/index.md).** This README.md is a template for repos to use. **If you have cloned this repo to start a new project** @@ -27,16 +28,16 @@ as the first paragraph of the introduction of your repo: - For Triton-related repos: ``` - This repository is part of the Joyent Triton project. See the [contribution - guidelines](https://github.com/joyent/triton/blob/master/CONTRIBUTING.md) + This repository is part of the Triton DataCenter project. See the [contribution + guidelines](https://github.com/TritonDataCenter/triton/blob/master/CONTRIBUTING.md) and general documentation at the main - [Triton project](https://github.com/joyent/triton) page. + [Triton project](https://github.com/TritonDataCenter/triton) page. ``` - For Manta-related repos: ``` - This repository is part of the Joyent Manta project. For contribution + This repository is part of the Manta project. For contribution guidelines, issues, and general documentation, visit the main - [Manta](http://github.com/joyent/manta) project page. + [Manta](http://github.com/TritonDataCenter/manta) project page. ``` After the boilerplate paragraph, write a brief description about your repo. @@ -45,9 +46,9 @@ After the boilerplate paragraph, write a brief description about your repo. To ensure maximum compatibility, release builds are performed on a build zone that is old enough to allow new and updated components to run on all supported -platform images. If you are not using the Joyent Jenkins instance for +platform images. If you are not using the Triton Jenkins instance for performing builds, you should build using an appropriate build zone. See -[Build Zone Setup for Manta and Triton](https://github.com/joyent/triton/blob/master/docs/developer-guide/build-zone-setup.md). +[Build Zone Setup for Manta and Triton](https://github.com/TritonDataCenter/triton/blob/master/docs/developer-guide/build-zone-setup.md). Describe steps necessary for development here. @@ -63,7 +64,7 @@ Describe steps necessary for testing here. ## Documentation -[Joyent Engineering Guide is at docs/index.md](docs/index.md). +[Triton Engineering Guide is at docs/index.md](docs/index.md). To update the guidelines, edit "docs/index.md" and run `make docs` to update "docs/index.html". Works on either SmartOS or Mac OS X. @@ -85,6 +86,6 @@ development data. ## License -"eng: Joyent Engineering Guide" is licensed under the +"eng: Triton Engineering Guide" is licensed under the [Mozilla Public License version 2.0](http://mozilla.org/MPL/2.0/). See the file LICENSE. diff --git a/docs/hybridimages.md b/docs/hybridimages.md index 32bc73c..16a86af 100644 --- a/docs/hybridimages.md +++ b/docs/hybridimages.md @@ -11,10 +11,10 @@ apisections: -# Joyent Hybrid Images +# Triton Hybrid Images This document describes the best practices for HVM image creation such that they are compatible with the QEMU/KVM and bhyve hypervisors on SmartOS. @@ -27,10 +27,10 @@ The key characteristics of a hybrid image are: locations in the device tree, perhaps with different model identifiers, serial numbers. etc. - Must configure networking using the [mdata - protocol](https://eng.joyent.com/mdata/protocol.html) on the second serial + protocol](https://eng.tritondatacenter.com/mdata/protocol.html) on the second serial port (`ttyS1`, `ttyb`, `COM2`, etc.). - Should take other actions as described in the [data - dictionary](https://eng.joyent.com/mdata/datadict.html). + dictionary](https://eng.tritondatacenter.com/mdata/datadict.html). - Should have an administrative port on the first serial port (`ttyS0`, `ttya`, `COM1`, etc.). - Should use virtio block and network devices. @@ -57,7 +57,7 @@ The typical hybrid image creation process involves the following steps. installation. This sanity check likely involves looking for well-known markers in the log output described above. 6. Generate an image, which is comprised of a zfs stream and a - [manifest](https://github.com/joyent/sdc-imgapi/blob/master/docs/index.md#image-manifests). + [manifest](https://github.com/TritonDataCenter/sdc-imgapi/blob/master/docs/index.md#image-manifests). 7. Optionally upload to Manta and/or https://updates.tritondatacenter.com. The steps described above are generally handled with automation. Steps 1, 2, @@ -125,16 +125,16 @@ vmadm start $uuid The following repositories follow the patterns described above. -* [mi-centos-hvm](https://github.com/joyent/mi-centos-hvm) for CentOS 6 - 8 -* [mi-debian-hvm](https://github.com/joyent/mi-debian-hvm) for Debian 8 - 10 +* [mi-centos-hvm](https://github.com/TritonDataCenter/mi-centos-hvm) for CentOS 6 - 8 +* [mi-debian-hvm](https://github.com/TritonDataCenter/mi-debian-hvm) for Debian 8 - 10 Each repo is intended to handle a family of distributions. The mi-centos-hvm repo probably implements the hard parts required for RHEL, Fedora, and other RHEL-derived distributions. Likewise, it should be straight-forward to add support for Ubuntu to mi-debian-hvm. -Each of those repositories has this ([eng](https://github.com/joyent/eng)) and -[sdc-vmtools](https://github.com/joyent/sdc-vmtools) as subrepos. The eng repo +Each of those repositories has this ([eng](https://github.com/TritonDataCenter/eng)) and +[sdc-vmtools](https://github.com/TritonDataCenter/sdc-vmtools) as subrepos. The eng repo is home to common tools used for building the images and the sdc-vmtools repo is used for things that are added to the image. @@ -235,7 +235,7 @@ have specialized control over the boot loader, etc., additional arguments can be specified on the command line. A key example of how this is used is in the [CentOS -images](https://github.com/joyent/mi-centos-hvm/blob/master/create-image).Rather +images](https://github.com/TritonDataCenter/mi-centos-hvm/blob/master/create-image).Rather than remastering the image to add the appropriate boot options, the installation media is mounted in the host and QEMU is started with options that specify the kernel, initrd, kernel command line, and a secondary CD which contains the diff --git a/docs/index.md b/docs/index.md index 002f412..1879c6a 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,5 +1,5 @@ --- -title: Joyent Engineering Guide +title: Triton Engineering Guide markdown2extras: tables, code-friendly apisections: --- @@ -11,12 +11,13 @@ apisections: -# Joyent Engineering Guide +# Triton Engineering Guide -This document describes standards and best practices for software development at -Joyent. These standards are intended to maintain product quality and to provide +This document describes standards and best practices for software development on +Triton. These standards are intended to maintain product quality and to provide consistency across codebases to make it easier for all engineers to learn new parts of the system. This latter goal is important to encourage everyone to feel comfortable diving into all parts of the system, as is often necessary when @@ -27,10 +28,9 @@ be followed blindly. However, these guidelines represent the best practices agreed upon by the team. If you feel it necessary to diverge from them, that's okay, but be prepared to explain why. -Note: In this document (and elsewhere at Joyent), a service implementing an API -is referred to by the API name itself. For example, "SAPI" denotes both the -"Services API" in the abstract as well as the software component that implements -that API. +Note: In this document, a service implementing an API is referred to by the API +name itself. For example, "SAPI" denotes both the "Services API" in the +abstract as well as the software component that implements that API. # Repository Guidelines @@ -62,20 +62,15 @@ being able to commit frequently. ## Repositories and documentation -Open-source projects and components live at github.com/joyent. These include -Node.js, SmartOS, Triton, Manta, and a large number of smaller Node modules and +Open-source projects and components live at github.com/TritonDataCenter. These +include SmartOS, Triton, Manta, and a large number of smaller Node modules and other components. Some components still live under individuals' github -accounts, but new components should generally be created under the "joyent" -organization. +accounts, but new components should generally be created under the +"TritonDataCenter" organization. Note that just because a repo is on github doesn't mean its issues are tracked there. That's decided on a per-project basis. -Some older components (and a few proprietary ones that are still used) are -managed by gitosis running on the internal Joyent git server. Files, commits, -and documentation for these projects can be browsed at mo.joyent.com by Joyent -employees. - ## Repository Naming @@ -194,7 +189,7 @@ Dependencies via `npm` can either take the form of an `npm` package name with a version specifier (in which case it must be published to the public `npm` package servers), or a `git` URL. -For externally developed packages not published by Joyent, version specifiers +For externally developed packages not published under Triton, version specifiers should always be used (and the package published to `npm`): "dependencies": { @@ -219,10 +214,10 @@ because it prevents users from being able to clone and build the package on a machine that does not have their GitHub private key on it. "dependencies": { - "joyent-module": "git+https://github.com/joyent/node-joyent-module.git#016977" + "triton-module": "git+https://github.com/TritonDataCenter/node-triton-module.git#016977" } -For certain dependencies, it is standard practice across the Joyent repositories +For certain dependencies, it is standard practice across the Triton repositories to use `git` submodules and not `npm`. This applies in particular to `javascriptlint`, `jsstyle`, `restdown`, `sdc-scripts` and some other modules that are not node.js-based. Similar to `npm` `git` dependencies, these must use @@ -230,12 +225,11 @@ that are not node.js-based. Similar to `npm` `git` dependencies, these must use [submodule "deps/javascriptlint"] path = deps/javascriptlint - url = https://github.com/davepacheco/javascriptlint.git + url = https://github.com/TritonDataCenter/javascriptlint.git Lastly, though you will find discussion about it in places, we don't currently use the npm "shrinkwrap" feature in any repositories. This is for a variety of -reasons, the discussion about which is far too involved to relate here (but feel -free to ask a senior Joyeur about the sordid history of SDC release management). +reasons, the discussion about which is far too involved to relate here. *[1]* There are a handful of exceptions here in cases where multiple logical node.js modules are combined in one repository (e.g. `ca-native` and `amon` @@ -251,8 +245,8 @@ tabs and tabstops). All styles **must** limit line length to 80 columns[1](#footnote1). Existing style-checking tools include: -* C: [cstyle](https://github.com/joyent/illumos-joyent/blob/master/usr/src/tools/scripts/cstyle.pl) -* JavaScript: [jsstyle](https://github.com/davepacheco/jsstyle), +* C: [cstyle](https://github.com/TritonDataCenter/illumos-joyent/blob/master/usr/src/tools/scripts/cstyle.pl) +* JavaScript: [jsstyle](https://github.com/TritonDataCenter/jsstyle), [gjslint](https://code.google.com/closure/utilities/docs/linter_howto.html), [eslint](http://eslint.org/) * Bash: bashstyle (contained in eng.git:tools/bashstyle) @@ -288,12 +282,12 @@ run [javascriptlint](http://github.com/davepacheco/javascriptlint) and/or not the same as style: lint covers objectively dangerous patterns like undeclared variables, while style covers subjective conventions like spacing. -All of `lint`, `javascriptlint`, and `eslint` are very configurable. See -[RFD 100](https://github.com/joyent/rfd/tree/master/rfd/0100) for eslint usage -in Joyent repositories. Projects may choose to enable and disable particular -sets of checks as they deem appropriate. Most checks can be disabled on a -per-line basis. As with style, it's recommended that we minimize divergence -between repositories. +All of `lint`, `javascriptlint`, and `eslint` are very configurable. See [RFD +100](https://github.com/TritonDataCenter/rfd/tree/master/rfd/0100) for eslint +usage in Triton repositories. Projects may choose to enable and disable +particular sets of checks as they deem appropriate. Most checks can be disabled +on a per-line basis. As with style, it's recommended that we minimize +divergence between repositories. Make target: "check" @@ -316,7 +310,7 @@ When modifying existing code, the year should be updated to be the current year that the file was modified. There should only be a single year, not a list. For example: - Copyright 2019 Joyent, Inc. + Copyright 2025 MNX Cloud, Inc. ## Testing @@ -326,17 +320,17 @@ for in-Triton systems tests (see boilerplate 'tools/runtests.in'). All repos **must** be tested by a comprehensive automated test suite and must be able to generate TAP output. (No particular node.js test framework is -required, but all things being equal, use "nodeunit" or "node-tap".) -These tests may be repo-specific, or may be part of a broader system test -suite (ideally both). In either case, bug fixes and new features should not -be integrated without adding new tests, and the tests **must** be run +required, but all things being equal, use "nodeunit" or "node-tap".) These +tests may be repo-specific, or may be part of a broader system test suite +(ideally both). In either case, bug fixes and new features should not be +integrated without adding new tests, and the tests **must** be run automatically (as via jenkins) either with every commit or daily. Currently -this is handled by the [nightly environment](https://github.com/joyent/globe-theatre/) -and the "stage-test-\*" Jenkins jobs. In other words, your project should -have some sort of "stage-test-\*" job. Understanding and fixing failures in -the automated test run **must** be considered the top development priority for -that repo's team. Persistent failures are not acceptable. Currently, these -nightly and CI environments can only be accessed by Joyent employees. +this is handled by the [nightly +environment](https://github.com/TritonDataCenter/globe-theatre/) and the +"stage-test-\*" Jenkins jobs. In other words, your project should have some +sort of "stage-test-\*" job. Understanding and fixing failures in the automated +test run **must** be considered the top development priority for that repo's +team. Persistent failures are not acceptable. All installed components **should** provide a "runtests" driver script (preferably in the "test" subdirectory) and the necessary test files @@ -402,9 +396,7 @@ Once the index is built, you can browse the source with: # cscope -dq -cscope is available for SmartOS in pkgsrc. It's also buildable on MacOS. For -instructions, see [the -wiki](https://hub.joyent.com/wiki/display/dev/Snow+Leopard+tips%2C+fixes+and+bugs). +cscope is available for SmartOS and macOS in pkgsrc. Make target: "xref" @@ -453,7 +445,7 @@ high level the component that's implemented in the file. For example: For non-trivial subsystems, consider adding a Big Theory statement that describes what the component does, the external interface, and internal details. For a great example, check out -[panic.c](https://github.com/joyent/illumos-joyent/blob/master/usr/src/uts/common/os/panic.c#L29) +[panic.c](https://github.com/TritonDataCenter/illumos-joyent/blob/master/usr/src/uts/common/os/panic.c#L29) in the kernel. Consider keeping design documents in restdown inside the repo. It's okay to have @@ -474,7 +466,7 @@ node build). There are two ways you can get a node build for your repo: "tools/mk/Makefile.node.targ". You'll also need a git submodule of the node sources: - $ git submodule add https://github.com/joyent/node.git deps/node + $ git submodule add https://github.com/nodejs/node.git deps/node $ cd deps/node $ git checkout v0.6.18 # select whichever version you want @@ -537,7 +529,7 @@ the comments and not in the JIRA tickets. ### Commit Comments -Across Joyent we require that **each commit be associated with one or more JIRA +Across Triton we require that **each commit be associated with one or more JIRA tickets and that those tickets be listed in the commit comments**. This way, given either the commit or the JIRA ticket, one can find the other. @@ -775,7 +767,7 @@ gather more information. To facilitate this: Service API endpoints **should** be named. Endpoint names **must** be CamelCase, **should** include the name of resource being operated on, and **should** follow the lead of -[CloudAPI](https://apidocs.joyent.com/cloudapi/) for verb usage, e.g.: +[CloudAPI](https://apidocs.tritondatacenter.com/cloudapi/) for verb usage, e.g.: # CRUD examples: ListMachines @@ -790,7 +782,7 @@ and **should** follow the lead of ResizeMachine # Example using "Put" verb from - # when the action + # when the action # is idempotent. PutObject @@ -1124,7 +1116,7 @@ rather than system scripts whose output goes to a log. # Java If you find yourself having to do anything related to Java or the Java Manta SDK -[QUICKSTART.md in java-manta](https://github.com/joyent/java-manta/blob/master/QUICKSTART.md) +[QUICKSTART.md in java-manta](https://github.com/TritonDataCenter/java-manta/blob/master/QUICKSTART.md) has a condensed guide for getting started and covers many aspects of our usage of Java and Maven that might not be familiar to an engineer that hasn't worked with these tools yet. @@ -1375,10 +1367,8 @@ See the top-level Makefile in eng.git for the complete details. # Software development process -Team synchronization begins daily with our morning scrum. We use continuous -integration with GitHub and Jenkins. Bugs and feature requests are tracked in -Jira. For more details on Joyent's morning scrum please read the: [Onboarding -Guide](https://mo.joyent.com/docs/engdoc/master/engguide/onboard.html#scrum). +We use continuous integration with GitHub and Jenkins. Bugs and feature +requests are tracked in Jira. In general, process is shrink-to-fit: we adopt process that help us work better, but process for process's sake is avoided. Any resemblance to formalized @@ -1386,7 +1376,11 @@ methodologies, living or dead, is purely coincidental. # Security Statement and Best Practices -Joyent Engineering makes security a top priority for all of our projects. All engineering work is expected to follow industry best practices. New changes affecting security are reviewed by a developer other than the person who wrote the new code. Both developers test that these changes are not vulnerable to the OWASP top 10 security, pass PCI DSS, and are safe. +Triton Engineering makes security a top priority for all of our projects. All +engineering work is expected to follow industry best practices. New changes +affecting security are reviewed by a developer other than the person who wrote +the new code. Both developers test that these changes are not vulnerable to the +OWASP top 10 security, pass PCI DSS, and are safe. Common vulnerabilities to watch out for: @@ -1400,7 +1394,7 @@ Common vulnerabilities to watch out for: ## Production code deployment process -For the Joyent Public Cloud, Jira change tickets should include the following before the code is promoted to production: +For the Public Cloud, Jira change tickets should include the following before the code is promoted to production: - Description of the change's impact - Record of approval by authorized stake holders @@ -1411,13 +1405,13 @@ For reference, read the [owasp top 10](https://www.owasp.org/index.php/Category: # Community Interaction -Due to the open source nature of Joyent software, community interaction is very +Due to the open source nature of Triton software, community interaction is very important. -There are mailing lists and IRC channels for top-level Joyent projects (Triton, -Manta, SmartOS). In addition to using these channels for assisting community -members with developing and using Joyent products, they are useful for notifying -the community of major changes. +There are mailing lists and IRC channels for top-level projects (Triton, Manta, +SmartOS). In addition to using these channels for assisting community members +with developing and using our products, they are useful for notifying the +community of major changes. ## Flag Day and Heads Up Notifications diff --git a/tools/buildimage/bin/buildimage b/tools/buildimage/bin/buildimage index 97f228c..304c6b7 100755 --- a/tools/buildimage/bin/buildimage +++ b/tools/buildimage/bin/buildimage @@ -7,7 +7,7 @@ /* * Copyright 2019 Joyent, Inc. - * Copyright 2022 MNX Cloud, Inc. + * Copyright 2025 MNX Cloud, Inc. */ var child_process = require('child_process'); @@ -572,13 +572,13 @@ function writeMotd(opts, callback) { imageInfo.manifest.name + '@' + imageInfo.manifest.version); // An example of the motd created here: - // = J O Y E N T = + // = T R I T O N = // - // manta-storage (master-20190628T124752Z-g1199325) - // git@github.com:joyent/manta-mako.git - // triton-origin-multiarch-18.1.0@1.0.1 + // ufds (release-20221215-20221215T002709Z-gb5661e9) + // https://github.com/tritondatacenter/sdc-ufds.git + // triton-origin-x86_64-21.4.0@master-20220322T012137Z-g9382491 // - var motd = ' = J O Y E N T =\n\n'; + var motd = ' = T R I T O N =\n\n'; motd += sprintf( ' %s (%s)\n', motd_data['name'], motd_data['stamp']); motd += sprintf(' %s\n', motd_data['source_repo']); diff --git a/tools/buildimage/lib/imgadm/lib/errors.js b/tools/buildimage/lib/imgadm/lib/errors.js index e5ec94e..3d1e2fb 100644 --- a/tools/buildimage/lib/imgadm/lib/errors.js +++ b/tools/buildimage/lib/imgadm/lib/errors.js @@ -21,6 +21,7 @@ * CDDL HEADER END * * Copyright 2020 Joyent, Inc. + * Copyright 2025 MNX Cloud, Inc. * * * * * Error classes that imgadm may produce. @@ -52,7 +53,7 @@ function _indent(s, indent) { * a string `code` (a CamelCase string). The possible codes are those * for every error subclass here, plus the possible `restCode` error * responses from IMGAPI. - * See . + * See . */ function ImgadmError(options) { assert.object(options, 'options'); @@ -132,7 +133,7 @@ util.inherits(ManifestValidationError, ImgadmError); * `requirements.min_platform` or `requirements.max_platform` fail. * * // JSSTYLED - * https://github.com/joyent/sdc-imgapi/blob/master/docs/index.md#manifest-requirementsmin_platform + * https://github.com/TritonDataCenter/sdc-imgapi/blob/master/docs/index.md#manifest-requirementsmin_platform */ function MinPlatformError(platVer, platTimestamp, minPlatSpec) { assert.string(platVer, 'platVer'); diff --git a/tools/buildimage/package.json b/tools/buildimage/package.json index dc2bba8..35e27c3 100644 --- a/tools/buildimage/package.json +++ b/tools/buildimage/package.json @@ -1,8 +1,8 @@ { "name": "buildimage", "description": "Triton Image Builder", - "version": "0.0.2", - "author": "Joyent (joyent.com)", + "version": "0.0.3", + "author": "MNX Cloud (mnx.io)", "private": true, "dependencies": { "assert-plus": "1.0.0", diff --git a/tools/check-copyright b/tools/check-copyright index 52f9304..18da657 100755 --- a/tools/check-copyright +++ b/tools/check-copyright @@ -7,13 +7,13 @@ # # Copyright 2020 Joyent, Inc. -# Copyright 2022 MNX Cloud, Inc. +# Copyright 2025 MNX Cloud, Inc. # # # Check that changed files (uncommitted and unpushed files) have the appropriate # MNX copyright year and blessed format, per: -# https://github.com/joyent/rfd/blob/master/rfd/0164/README.md#copyright-notice +# https://github.com/TritonDataCenter/rfd/blob/master/rfd/0164/README.md#copyright-notice # # Usage: Run this anywhere in your git clone. # diff --git a/tools/create-hybrid-image b/tools/create-hybrid-image index 8aeef71..ec6ec09 100755 --- a/tools/create-hybrid-image +++ b/tools/create-hybrid-image @@ -8,6 +8,7 @@ # # Copyright 2022 Joyent, Inc. +# Copyright 2025 MNX Cloud, Inc. # if [[ -n "$TRACE" ]]; then @@ -37,7 +38,7 @@ cat < +# # # Need GNU awk for multi-char arg to "-F". _AWK := $(shell (which gawk >/dev/null && echo gawk) \ diff --git a/tools/mk/Makefile.node.targ b/tools/mk/Makefile.node.targ index a62f2e2..e46cfdd 100644 --- a/tools/mk/Makefile.node.targ +++ b/tools/mk/Makefile.node.targ @@ -6,6 +6,7 @@ # # Copyright (c) 2019, Joyent, Inc. +# Copyright (c) 2025 MNX Cloud, Inc. # # @@ -38,7 +39,7 @@ else $(NODE_EXEC) $(NPM_EXEC) $(NODE_WAF_EXEC): (mkdir -p $(BUILD) \ && cd $(BUILD) \ - && [[ -d src-node ]] && (cd src-node && git checkout master && git pull) || git clone https://github.com/joyent/node.git src-node \ + && [[ -d src-node ]] && (cd src-node && git checkout master && git pull) || git clone https://github.com/nodejs/node.git src-node \ && cd src-node \ && git checkout $(NODE_PREBUILT_VERSION) \ && ./configure $(NODE_CONFIG_FLAGS) \ diff --git a/tools/mk/Makefile.node_prebuilt.defs b/tools/mk/Makefile.node_prebuilt.defs index 7c46bd4..0f6ae73 100644 --- a/tools/mk/Makefile.node_prebuilt.defs +++ b/tools/mk/Makefile.node_prebuilt.defs @@ -6,7 +6,7 @@ # # Copyright 2020 Joyent, Inc. -# Copyright 2024 MNX Cloud, Inc. +# Copyright 2025 MNX Cloud, Inc. # # @@ -127,7 +127,7 @@ # build (say the developer changes NODE_PREBUILT_VERSION) will recreate the # node install. # -# See for details on 'sdcnode-*' +# See for details on 'sdcnode-*' # package naming. # diff --git a/tools/mkrepo b/tools/mkrepo index c06d75a..98b51be 100755 --- a/tools/mkrepo +++ b/tools/mkrepo @@ -7,7 +7,8 @@ */ /* - * Copyright (c) 2019, Joyent, Inc. + * Copyright (c) 2019 Joyent, Inc. + * Copyright (c) 2025 MNX Cloud, Inc. */ var child_process = require('child_process'); @@ -30,10 +31,10 @@ var DIRS = [ ]; var SUBMODULES = { - 'eng': 'https://github.com/joyent/eng.git', - 'javascriptlint': 'https://github.com/davepacheco/javascriptlint.git', - 'jsstyle': 'https://github.com/davepacheco/jsstyle.git', - 'restdown': 'https://github.com/trentm/restdown.git' + 'eng': 'https://github.com/TritonDataCenter/eng.git', + 'javascriptlint': 'https://github.com/TritonDataCenter/javascriptlint.git', + 'jsstyle': 'https://github.com/TritonDataCenter/jsstyle.git', + 'restdown': 'https://github.com/TritonDataCenter/restdown.git' }; @@ -81,7 +82,7 @@ function mkdir(d) { function gitify(dir, repo) { exec('git init', dir, function () { - exec('git remote add origin git@github.com:joyent/' + repo + '.git', + exec('git remote add origin git@github.com:TritonDataCenter/' + repo + '.git', dir); Object.keys(SUBMODULES).forEach(function (k) { diff --git a/tools/runtests.in b/tools/runtests.in index 2386dac..88d9216 100644 --- a/tools/runtests.in +++ b/tools/runtests.in @@ -6,7 +6,8 @@ # # -# Copyright (c) 2014, Joyent, Inc. +# Copyright (c) 2014 Joyent, Inc. +# Copyright (c) 2025 MNX Cloud, Inc. # # @@ -113,7 +114,7 @@ mkdir -p $OUTPUT_DIR # - If reasonable, use $opt_test_pattern to filter the set of test files run. # # Some examples: -# - https://github.com/joyent/sdcadm/blob/master/test/runtests +# - https://github.com/TritonDataCenter/sdcadm/blob/master/test/runtests retval=0 exit $retval diff --git a/tools/validate-buildenv.sh b/tools/validate-buildenv.sh index 7bd7d7e..2c12b4b 100755 --- a/tools/validate-buildenv.sh +++ b/tools/validate-buildenv.sh @@ -7,15 +7,15 @@ # # Copyright 2022 Joyent, Inc. -# Copyright 2024 MNX Cloud, Inc. +# Copyright 2025 MNX Cloud, Inc. # # # Check if the current build machine is supported for building this component # and that the build environment seems sane. # -# Most Joyent software is built using a common build environment described in -# https://github.com/joyent/triton/blob/master/docs/developer-guide/build-zone-setup.md. +# Most Triton software is built using a common build environment described in +# https://github.com/TritonDataCenter/triton/blob/master/docs/developer-guide/build-zone-setup.md. # The quickest path to having a sane build environment likely involves following # that document. # @@ -87,6 +87,9 @@ declare -A PKGSRC_MAP=( [59ba2e5e-976f-4e09-8aac-a4a7ef0395f5]=2019Q4 [a7199134-7e94-11ec-be67-db6f482136c2]=2021Q4 [502eeef2-8267-489f-b19c-a206906f57ef]=2021Q4 + [41bd4100-eb86-409a-85b0-e649aadf6f62]=2024Q4 + [4dd8810e-10a8-49d1-b37b-1c4e32ed6c05]=2024Q4 + ) # Used to provide useful error messages to the user, mapping the @@ -101,11 +104,13 @@ declare -A SDC_MAP=( [59ba2e5e-976f-4e09-8aac-a4a7ef0395f5]=triton-origin-x86_64-19.4.0@master-20200130T200825Z-gbb45b8d [a7199134-7e94-11ec-be67-db6f482136c2]=minimal-64-lts@21.4.0 [502eeef2-8267-489f-b19c-a206906f57ef]=triton-origin-x86_64-21.4.0@master-20220322T012137Z-g9382491 + [41bd4100-eb86-409a-85b0-e649aadf6f62]=minimal-64-lts@24.4.1 + [4dd8810e-10a8-49d1-b37b-1c4e32ed6c05]=triton-origin-x86_64-24.4.1@master-20250116T175211Z-gb17eb8e ) # Used to provide useful error messages to the user, mapping the NODE_PREBUILT # image uuid to a corresponding jenkins-agent image uuid. -# Jenkins agent images are built by https://github.com/joyent/jenkins-agent +# Jenkins agent images are built by https://github.com/TritonDataCenter/jenkins-agent declare -A JENKINS_AGENT_MAP=( [fd2cc906-8938-11e3-beab-4359c665ac99]=3e8e972d-1d38-4b68-a3b2-00861b2ec89a [18b094b0-eb01-11e5-80c1-175dac7ddf02]=f00a393d-a1c8-4e93-a13e-c364a7d0a2a9 @@ -384,7 +389,7 @@ function validate_delegated_dataset { has_delegated_ds=$(zfs list -H -o name zones/$zonename/data 2>/dev/null) if [[ -z "$has_delegated_ds" ]]; then - local djc_base="https://docs.joyent.com/private-cloud/instances/" + local djc_base="https://docs.tritondatacenter.com/private-cloud/instances/" echo "The current devzone does not have a delegated zfs dataset," echo "which is required for 'buildimage' to function." echo "Please recreate this devzone, ensuring it has a delegated ds." @@ -521,7 +526,10 @@ function validate_pkgsrc_pkgs { # /opt/local/bin. # function validate_opt_tools { - if [[ ! -f /opt/tools/bin/pkgin ]]; then + # Modern releases have no need for /opt/tools + if [[ "$PKGSRC_RELEASE" == "2024Q4" ]]; then + return 0 + elif [[ ! -f /opt/tools/bin/pkgin ]]; then local JENKINS_IMAGE="${JENKINS_AGENT_MAP[${REQUIRED_IMAGE}]}" echo "This build zone is missing /opt/tools/bin, which is" @@ -742,7 +750,7 @@ else echo "Build zone setup typically requires almost no work if you are" echo "using the right image. See:" echo "" - echo "https://github.com/joyent/triton/blob/master/docs/developer-guide/build-zone-setup.md" + echo "https://github.com/TritonDataCenter/triton/blob/master/docs/developer-guide/build-zone-setup.md" echo "" exit 1