https://github.com/zowe/zowe-install-packaging
Packaging repository for the Zowe install scripts and files
https://github.com/zowe/zowe-install-packaging
Last synced: about 1 year ago
JSON representation
Packaging repository for the Zowe install scripts and files
- Host: GitHub
- URL: https://github.com/zowe/zowe-install-packaging
- Owner: zowe
- License: epl-2.0
- Created: 2018-08-13T14:40:34.000Z (almost 8 years ago)
- Default Branch: v3.x/staging
- Last Pushed: 2024-10-30T04:52:42.000Z (over 1 year ago)
- Last Synced: 2024-10-30T04:59:05.522Z (over 1 year ago)
- Language: Shell
- Homepage:
- Size: 22.6 MB
- Stars: 27
- Watchers: 26
- Forks: 51
- Open Issues: 316
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
README
# zowe-install-packaging
This repository includes Zowe installation script and pipelines to build Zowe.
- [Branches](#branches)
- [Manifest File](#manifest-file)
- [General information](#general-information)
- [Build information](#build-information)
- [Binary Dependencies](#binary-dependencies)
- [Source Dependencies](#source-dependencies)
- [Point of Contacts](#point-of-contacts)
- [Build Pipeline](#build-pipeline)
- [Generate Customized Zowe Build](#generate-customized-zowe-build)
- [Automate Install / Uninstall of Zowe with Ansible](#automate-install--uninstall-of-zowe-with-ansible)
- [Quick Sanity Check on Your Zowe Instance](#quick-sanity-check-on-your-zowe-instance)
## Branches
- From `master` branch, you can find the most recent **stable** build. It matches to the most recent official Zowe release.
- `rc` branch means release candidate and is mainly for release usage. It's an intermediate state where we hold the code to prepare for the coming release. This branch is merged from `staging` and eventually if Release Candidate builds are tested passed, this branch will be merged into `master` to announce a formal release.
- `staging` branch is targeted to the next release and holds the most recent development progress. Normally a development changes may result in a Pull Request against this branch.
- `v?.x/*` branches are for past and future purpose. It may also have `v?.x/master` and `v?.x/staging`, etc.
Pull Request is required to merge changes to `staging`, `rc`. Generally `master` doesn't accept Pull Request to make feature changes or bug fixes.
## Manifest File
Zowe include several components. `manifest.json.template` defines general information of Zowe and how components are included into official build.
The manifest file include these sections:
### General information
These information are represented in these properties: `name`, `version`, `description`, `license` and `homepage`.
### Build information
These information includes details when building the Zowe artifact. During build process, `manifest.json.template` will be converted to `manifest.json` and the template variables like `{BUILD_COMMIT_HASH}` will be filled in with real value. The modified `manifest.json` will be placed into root folder of Zowe build.
Here is an example of build information after build, you can find it in the `manifest.json` file from every Zowe build:
```
"build": {
"branch": "staging",
"number": "202",
"commitHash": "dad00f0a9c45f34bfbe3ec56a8443f2e818e59f4",
"timestamp": "1568205429441"
},
```
The above build information means this Zowe build is from `staging` branch build #202, git commit hash is [dad00f0a9c45f34bfbe3ec56a8443f2e818e59f4](https://github.com/zowe/zowe-install-packaging/commit/dad00f0a9c45f34bfbe3ec56a8443f2e818e59f4). Build time is `1568205429441`, which means `Wed Sep 11 2019 08:37:09 GMT-0400 (Eastern Daylight Time)`.
### Binary Dependencies
`binaryDependencies` section defines how many components will be included into the binary build. Each component has an unique ID, which hints where the pipeline should pick up the component artifact. Also for each the component, it defines which version will be included into the build.
Here is an example of component definition:
```
"org.zowe.explorer.jobs": {
"version": "~0.2.8-STAGING",
"explode": "true"
}
```
`org.zowe.explorer.jobs` is the component ID, which also tell the pipeline to pick the component from Artifactory path `/org/zowe/explorer/jobs/`. `version` defines which version we should pick. In this case, we should pick the max version matches `0.2.*-STAGING` and `>= 0.2.8-STAGING`. So version `0.2.10-STAGING` is a good match if it exists.
For details of **how to define a component**, please check examples and explanations from https://zowe.github.io/jenkins-library/jenkins_shared_library/artifact/JFrogArtifactory.html#interpretArtifactDefinition(java.lang.String,%20java.util.Map,%20java.util.Map).
### Source Dependencies
`sourceDependencies` section defines how the component binary matches to the Zowe github repository, branch or tag. It is grouped by `componentGroup`. For example, `Zowe Application Framework` componentGroup includes all repositories related it and listed in `entries` section.
One example component entry looks like:
```
{
"repository": "imperative",
"tag": "v2.4.9"
}
```
This means the Zowe build is using https://github.com/zowe/imperative repository tag [v2.4.9](https://github.com/zowe/imperative/tree/v2.4.9).
**Please note, this section may not reflect the correct value for non-formal-release.** Only for formal releases, we will update these sections to match the correct repository tags.
To check for each release, what source code from repositories will be used, you can:
- go to https://github.com/zowe/zowe-install-packaging,
- click on [?? releases](https://github.com/zowe/zowe-install-packaging/releases),
- find the release name. For example [v1.4.0](https://github.com/zowe/zowe-install-packaging/releases/tag/v1.4.0),
- click on the tag name on the left. In the above case, it shows [v1.4.0](https://github.com/zowe/zowe-install-packaging/tree/v1.4.0),
- find and check file `manifest.json.template`. In the above case, it links to [v1.4.0/manifest.json.template](https://github.com/zowe/zowe-install-packaging/blob/v1.4.0/manifest.json.template).
- check the `sourceDependencies` section. In the above case, it's line #96.
- In the above example, you will see Zowe release v1.4.0 is using https://github.com/zowe/imperative repository tag [v2.4.9](https://github.com/zowe/imperative/tree/v2.4.9).
### Point of Contacts
For each Zowe component, we have point of contact(s) in case if we want to confirm the versions defined in the `manifest.json.template`:
- API Mediation Layer: Elliot Jalley, Mark Ackert
* Binary Dependencies
- org.zowe.apiml.sdk.zowe-install
* Source Dependencies
- api-layer
- zLux, ZSS and Cross Memory Server: James Struga
* Binary Dependencies
- org.zowe.zlux.sample-angular-app
- org.zowe.zlux.sample-iframe-app
- org.zowe.zlux.sample-react-app
- org.zowe.zlux.tn3270-ng2
- org.zowe.zlux.vt-ng2
- org.zowe.zlux.zlux-core
- org.zowe.zlux.zlux-editor
- org.zowe.zss
* Source Dependencies
- zlux-app-manager
- zlux-app-server
- zlux-file-explorer
- zlux-grid
- zlux-platform
- zlux-server-framework
- zlux-shared
- zlux-widgets
- zlux-build
- zss
- zowe-common-c
- tn3270-ng2
- sample-angular-app
- sample-iframe-app
- sample-react-app
- vt-ng2
- zlux-editor
- Explorer APIs / UI Plugins: Jordan Cain
* Binary Dependencies
- org.zowe.explorer-jes
- org.zowe.explorer-mvs
- org.zowe.explorer-uss
* Source Dependencies
- explorer-api-common
- explorer-jes
- explorer-mvs
- explorer-uss
- orion-editor-component
- explorer-ui-server
- CLI: Fernando Rijo Cedeno, Mark Ackert
* Source Dependencies
- imperative
- zowe-cli
- zowe-cli-cics-plugin
- zowe-cli-db2-plugin
- perf-timing
- zowe-cli-mq-plugin
- zowe-cli-scs-plugin
- zowe-cli-ftp-plugin
- Explorer (Visual Studio Code Extension): Fernando Rijo Cedeno, Mark Ackert
* Source Dependencies
- zowe-explorer-vscode
- License: Mark Ackert
* Binary Dependencies
- org.zowe.licenses
## Build Pipeline
Zowe build pipeline has hooked into github repository. Every branch, commit and PR has potential to kick off a new Zowe build. If the build is not automatically started, you can go to Jenkins and start a build job on the appropriated branch or pull request.
### Generate Customized Zowe Build
If your changes are in `zowe-install-packaging`, you may already have a Zowe build if you have a branch. Otherwise you will have one if you create a pull request on your changes.
If your changes are in components, it may depend on how the Zowe build picks your changes:
- If you have released, or have a snapshot build of your component, very likely the change will be picked up by the `staging` branch build. If not, you need to check the `binaryDependencies` section in `manifest.json.template`.
- If your changes is still in a branch of the component repository, you can edit `manifest.json.template` to use the branch build directly like this:
```
"org.zowe.explorer.jobs": {
"artifact": "lib-snapshot-local/org/zowe/explorer/jobs/0.2.7-MY-BRANCH-BUILD.zip",
"explode": "true"
},
```
### Writing HOLDDATA
If your changes require end-users to take action on their system beyond applying maintenance and recycling the Zowe address space, you will need to write HOLDDATA detailing what steps the user should take once the maintenance is applied.
HOLDDATA should be written in a `smpe/bld/service/current-hold-*.txt` file. More details on this file format can be found in [the SMP/e service doc](./smpe/bld/service/_README.txt).
## Automate Install / Uninstall of Zowe with Ansible
Please check details in [playbooks folder](playbooks/README.md).
## Quick Sanity Check on Your Zowe Instance
Please check details in [sanity test folder](tests/sanity/README.md).
Hosting infrastructure for this project is supported by:
